home *** CD-ROM | disk | FTP | other *** search
/ Info-Mac 4 / Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso / Periodicals / CSMP / C.S.M.P. Digest, Issue 3.006 < prev    next >
Internet Message Format  |  1994-06-09  |  631KB

  1. From: pottier@clipper.ens.fr (Francois Pottier)
  2. Subject: C.S.M.P. Digest, Issue 3.006
  3. Date: Fri, 18 Mar 94 16:15:51 MET
  4.  
  5. C.S.M.P. Digest             Fri, 18 Mar 94       Volume 3 : Issue 6
  6.  
  7. Today's Topics:
  8.  
  9.         68K emulation and PPC toolbox questions.
  10.         AE coercion handlers ?
  11.         ARGH!!! Whamwhamwham!! (DialogSelect stuff)
  12.         An offering: Assembly language code for a high speed copybits
  13.         Animation speed: here we go again...
  14.         Animation speed: improvement!
  15.         Animation speed: more info
  16.         Animation: the story continues...
  17.         Blank Screen?
  18.         C code for scrollable application help
  19.         Can C be as fast as Assembler? (next...on the McLaughlin Group)
  20.         Color Terminal Emulator
  21.         DrawString + Ellipsis character ?
  22.         Finder comments on non-Desktop DB volumes?
  23.         Finding System Folder (Again)
  24.         Free code:  Sean's window manager
  25.         How does the Finder handle events?
  26.         How to determine color of progress bar?
  27.         How to draw inits icons?
  28.         How to tell a Mac from a Mac?
  29.         I know the Mac MM isn't reentrant, but:
  30.         If you use SysBeep() for debugging...
  31.         Improving DrawText speed (Was: Color Terminal Emulator)
  32.         Interface guidelines for extra program files
  33.         Intermixing graphics and text
  34.         Let's kill 24-bit mode! (was Re: Let's kill System 6!)
  35.         Let's kill system 6!
  36.         Never beep when using GWorlds. System software bug!
  37.         PPC & 68k UPP problems
  38.         PPC binaries
  39.         Passing data through to completion procs?
  40.         Password editing item.. Tricky?
  41.         Permanent front windows...
  42.         Preference file question!
  43.         Reading PICT files != 72 dpi. How ?
  44.         Resources on PowerPC
  45.         Safer Segments ?
  46.         Speeding up animation; questions
  47.         System Folder on NONstartup disk
  48.         Trap dispatcher overhead
  49.         User in a menu?
  50.         What happens if my Vertical Retrace task takes too long?
  51.         When to StripAddress?  (was Re: Let's kill 24-bit mode!)
  52.         Why can't I have AEs *in* AEs?
  53.         Why use handles at all, though?
  54.         Writing To Screen Memory
  55.         dirIDs
  56.         jGNEFilter Q
  57.         password encryption
  58.  
  59.  
  60.  
  61. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  62. (pottier@clipper.ens.fr).
  63.  
  64. The digest is a collection of article threads from the internet newsgroup
  65. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  66. regularly and want an archive of the discussions.  If you don't know what a
  67. newsgroup is, you probably don't have access to it.  Ask your systems
  68. administrator(s) for details.  If you don't have access to news, you may
  69. still be able to post messages to the group by using a mail server like
  70. anon.penet.fi (mail help@anon.penet.fi for more information).
  71.  
  72. Each issue of the digest contains one or more sets of articles (called
  73. threads), with each set corresponding to a 'discussion' of a particular
  74. subject.  The articles are not edited; all articles included in this digest
  75. are in their original posted form (as received by our news server at
  76. nef.ens.fr).  Article threads are not added to the digest until the last
  77. article added to the thread is at least two weeks old (this is to ensure that
  78. the thread is dead before adding it to the digest).  Article threads that
  79. consist of only one message are generally not included in the digest.
  80.  
  81. The digest is officially distributed by two means, by email and ftp.
  82.  
  83. If you want to receive the digest by mail, send email to listserv@ens.fr
  84. with no subject and one of the following commands as body:
  85.     help                        Sends you a summary of commands
  86.     subscribe csmp-digest Your Name    Adds you to the mailing list
  87.     signoff csmp-digest            Removes you from the list
  88. Once you have subscribed, you will automatically receive each new
  89. issue as it is created.
  90.  
  91. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  92. Questions related to the ftp site should be directed to
  93. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  94. digest are available there.
  95.  
  96. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.
  97.  
  98.  
  99. -------------------------------------------------------
  100.  
  101. >From herman@ece.cmu.edu (Herman Schmit)
  102. Subject: 68K emulation and PPC toolbox questions.
  103. Date: 16 Mar 1994 19:32:32 GMT
  104. Organization: Electrical and Computer Engineering, Carnegie Mellon
  105.  
  106.  
  107.  
  108. When doing 68K emulation, will a Power Mac do emulation of 68K toolbox
  109. routines, or does the emulator detect those routines and execute the
  110. PowerPC toolbox code for that routine?
  111.  
  112. I'm also curious exactly why there will not be a 68K->PowerPC machine
  113. code translator in addition to an emulator.  I always thought that the
  114. problem with translating between CPUs was not caused by different
  115. instruction sets but by different system/OS calls and different memory
  116. models.  If the toolbox will be the same, the system/OS calls are no
  117. longer a problem.  Do the Power Macs have a significantly different
  118. memory model?
  119.  
  120. Even if they have a different memory model, couldn't you do some sort
  121. of emulation of the 68K memory and translate the everything else into
  122. PPC native code?  Or is this what is done?
  123.  
  124. herman
  125.  
  126.  
  127. +++++++++++++++++++++++++++
  128.  
  129. >From rang@winternet.mpls.mn.us (Anton Rang)
  130. Date: 17 Mar 1994 05:13:49 GMT
  131. Organization: Minnesota Angsters
  132.  
  133. In article <2m7msg$s9f@fs7.ece.cmu.edu> herman@ece.cmu.edu (Herman Schmit) writes:
  134. >When doing 68K emulation, will a Power Mac do emulation of 68K toolbox
  135. >routines, or does the emulator detect those routines and execute the
  136. >PowerPC toolbox code for that routine?
  137.  
  138.   The emulator detects A-traps and dispatches them through the trap
  139. table, as happens on 68K machines.  If the trap is written in PowerPC
  140. code, the Mixed Mode Manager switches to PowerPC native mode (if
  141. needed) and then runs it.  Similarly, if the trap is in 68K code, the
  142. MMM switches to 68K emulation and then runs it.
  143.  
  144. >I'm also curious exactly why there will not be a 68K->PowerPC machine
  145. >code translator in addition to an emulator.  I always thought that the
  146. >problem with translating between CPUs was not caused by different
  147. >instruction sets but by different system/OS calls and different memory
  148. >models.
  149.  
  150.   First, there is at least one third-party translator available,
  151. FlashPort by Echo Logic.  But it requires some input from the
  152. developers to do a good job; you can't just drag-and-drop onto it.
  153.  
  154.   Second, both problems exist.  It's not trivial to convert between
  155. different code models *and get reasonable performance*.  It can be
  156. done -- VEST on DEC's Alpha VMS machines is truly incredible! -- but
  157. it's very state-of-the-art and probably would have cost Apple many
  158. millions to develop....
  159. --
  160. Anton Rang (rang@winternet.mpls.mn.us)
  161.  
  162. +++++++++++++++++++++++++++
  163.  
  164. >From zstern@adobe.com (Zalman Stern)
  165. Date: Fri, 18 Mar 1994 11:55:45 GMT
  166. Organization: Adobe Systems Incorporated
  167.  
  168. Anton Rang writes
  169. > In article <2m7msg$s9f@fs7.ece.cmu.edu> herman@ece.cmu.edu (Herman Schmit)  
  170. writes:
  171. > >When doing 68K emulation, will a Power Mac do emulation of 68K toolbox
  172. > >routines, or does the emulator detect those routines and execute the
  173. > >PowerPC toolbox code for that routine?
  174. >   The emulator detects A-traps and dispatches them through the trap
  175. > table, as happens on 68K machines.  If the trap is written in PowerPC
  176. > code, the Mixed Mode Manager switches to PowerPC native mode (if
  177. > needed) and then runs it.  Similarly, if the trap is in 68K code, the
  178. > MMM switches to 68K emulation and then runs it.
  179.  
  180. In addition, some traps are "fat" and provide both 68K and PowerPC code.  
  181. This avoids the overhead of a mixed-mode switch for very small routines.  
  182. (Like say SetPort and GetPort.) All of the above applies to any routine  
  183. descriptor, not just the ones placed in the trap table. The most common use  
  184. is for callbacks passed to toolbox routines, however they can be used within  
  185. your own code as well. (There is special support in Mixed Mode to handle the  
  186. dispatching and calling conventions of traps of course.)
  187. --
  188. Zalman Stern           zalman@adobe.com            (415) 962 3824
  189. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  190. "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)
  191.  
  192. ---------------------------
  193.  
  194. >From paulr@syma.sussex.ac.uk (Paul Russell)
  195. Subject: AE coercion handlers ?
  196. Date: Wed, 2 Mar 1994 16:31:54 GMT
  197. Organization: University of Sussex
  198.  
  199. Am I right in thinking that there are no default
  200. system AE coercion handlers ? Not even for such 
  201. basic conversions as typeChar<->typeExtended ?
  202.  
  203. Is there a utility for displaying the installed
  204. coercion handlers ?
  205.  
  206. Are there any available handlers for common
  207. types, either as source or as an extension ?
  208.  
  209. //Paul
  210.  
  211. -- 
  212. |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  213. |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  214. |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  215. |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  216.  
  217. +++++++++++++++++++++++++++
  218.  
  219. >From jwbaxter@olympus.net (John W. Baxter)
  220. Date: Wed, 02 Mar 1994 12:43:30 -0800
  221. Organization: Internet for the Olympic Peninsula
  222.  
  223. In article <1994Mar2.163154.19747@syma.sussex.ac.uk>,
  224. paulr@syma.sussex.ac.uk (Paul Russell) wrote:
  225.  
  226. > Am I right in thinking that there are no default
  227. > system AE coercion handlers ? Not even for such 
  228. > basic conversions as typeChar<->typeExtended ?
  229.  
  230. There are a bunch of coercions built in to the Apple Event Manager.  As it
  231. happens, typeChar<->typeExtended is one of them.  They are listed in Inside
  232. Mac: IAC in table 4-1, which occupies ALL of pages 4-43 and 4-44.
  233.  
  234. There are more "exotic" ones built in, too, such as typeAppleEvent -->
  235. typeAppParameters (by far the easiest way to build THAT monster).
  236.  
  237. > Is there a utility for displaying the installed
  238. > coercion handlers ?
  239.  
  240. Yes...there is a little FKey.  It puts up a nice list of all the
  241. Application handlers (event, coercion, object extraction, etc) for the
  242. front application, and all the System handlers.  It is broken when the
  243. current Finder is in front [if it hurts, don't do it].  It's on the
  244. Developer CDs...since it is there, I don't know where else it may be.  It
  245. can also be used to trigger the handlers, although I haven't exercised that
  246. ability.
  247.  
  248. > Are there any available handlers for common
  249. > types, either as source or as an extension ?
  250.  
  251. AppleScript installs a whole bunch more.  And they are multiplying on the
  252. net.  They can get pretty much as outrageous as you may want.  I suppose a
  253. hypothetical typeRTF -> hypothetical typePostScript would be possible (but
  254. not written by me).
  255.  
  256. -- 
  257. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  258.    jwbaxter@pt.olympus.net
  259.  
  260. +++++++++++++++++++++++++++
  261.  
  262. >From paulr@syma.sussex.ac.uk (Paul Russell)
  263. Date: Thu, 3 Mar 1994 13:49:08 GMT
  264. Organization: University of Sussex
  265.  
  266. John W. Baxter (jwbaxter@olympus.net) wrote:
  267. : In article <1994Mar2.163154.19747@syma.sussex.ac.uk>,
  268. : paulr@syma.sussex.ac.uk (Paul Russell) wrote:
  269.  
  270. : > Am I right in thinking that there are no default
  271. : > system AE coercion handlers ? Not even for such 
  272. : > basic conversions as typeChar<->typeExtended ?
  273.  
  274. : There are a bunch of coercions built in to the Apple Event Manager.  As it
  275. : happens, typeChar<->typeExtended is one of them.  They are listed in Inside
  276. : Mac: IAC in table 4-1, which occupies ALL of pages 4-43 and 4-44.
  277.  
  278. : There are more "exotic" ones built in, too, such as typeAppleEvent -->
  279. : typeAppParameters (by far the easiest way to build THAT monster).
  280.  
  281. Thanks for the above and the rest of your comments - it looks like I
  282. have some sort of problem. I tried writing a small program which just
  283. calls AEGetCoercionHandler for a few different types and I get a -1717
  284. for everything I've tried. I have Apple Event Manager 1.0.1 and
  285. AppleScript 1.0 installed and am running System 7.1. I think both
  286. Apple Event Manager 1.0.1 and AppleScript 1.0 may be out of date
  287. by now so I'll have a dig through the developer CD's and see if
  288. I can find something newer.
  289.  
  290. //Paul
  291. -- 
  292. |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  293. |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  294. |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  295. |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  296.  
  297. +++++++++++++++++++++++++++
  298.  
  299. >From isis@netcom.com (Mike Cohen)
  300. Date: Thu, 3 Mar 1994 01:48:50 GMT
  301. Organization: ISIS International
  302.  
  303. paulr@syma.sussex.ac.uk (Paul Russell) writes:
  304.  
  305. >Am I right in thinking that there are no default
  306. >system AE coercion handlers ? Not even for such 
  307. >basic conversions as typeChar<->typeExtended ?
  308.  
  309. >Is there a utility for displaying the installed
  310. >coercion handlers ?
  311.  
  312. >Are there any available handlers for common
  313. >types, either as source or as an extension ?
  314.  
  315. >//Paul
  316.  
  317. There are default handlers for most numeric types to/from text and from
  318. alias to FSSpec. With AppleScript installed, there are many more coercion
  319. handlers available.
  320. -- 
  321. Mike Cohen - isis@netcom.com
  322. NewtonMail: MikeC49506 / ALink: D6734 / AOL: MikeC20
  323.  
  324.  
  325. +++++++++++++++++++++++++++
  326.  
  327. >From paulr@syma.sussex.ac.uk (Paul Russell)
  328. Date: Fri, 4 Mar 1994 13:20:57 GMT
  329. Organization: University of Sussex
  330.  
  331. Mike Cohen (isis@netcom.com) wrote:
  332. : paulr@syma.sussex.ac.uk (Paul Russell) writes:
  333.  
  334. : >Am I right in thinking that there are no default
  335. : >system AE coercion handlers ? Not even for such 
  336. : >basic conversions as typeChar<->typeExtended ?
  337.  
  338. : >Is there a utility for displaying the installed
  339. : >coercion handlers ?
  340.  
  341. : >Are there any available handlers for common
  342. : >types, either as source or as an extension ?
  343.  
  344. : >//Paul
  345.  
  346. : There are default handlers for most numeric types to/from text and from
  347. : alias to FSSpec. With AppleScript installed, there are many more coercion
  348. : handlers available.
  349.  
  350. Thanks - I found the FKEY that displays the installed handlers and
  351. although there is a motley assortment of coercion handlers, none
  352. of the expected handlers for text<->float etc seem to be available.
  353. This appears to be the case on several Macs that I have tried this on,
  354. and I have also written a test program which calls AEGetCoercionHandler
  355. which returns -1717 for just about any pair of types I try.
  356.  
  357. My best guess is that this is something to do with localisation - I am
  358. wondering if the US version of the Apple Event Manager/Apple Script
  359. checks the system version and doesn't install any handlers which might
  360. be country-specific ? 
  361.  
  362. If the above is not the correct explanation then I'd be interested to
  363. hear any other possible explanations for why the usual handlers aren't
  364. available ?
  365.  
  366. //Paul
  367.  
  368. -- 
  369. |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  370. |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  371. |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  372. |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  373.  
  374. +++++++++++++++++++++++++++
  375.  
  376. >From lai@apple.com (Ed Lai)
  377. Date: 4 Mar 1994 23:32:40 GMT
  378. Organization: Apple
  379.  
  380. In article <1994Mar4.132057.18343@syma.sussex.ac.uk>,
  381. paulr@syma.sussex.ac.uk (Paul Russell) wrote:
  382.  
  383. > Mike Cohen (isis@netcom.com) wrote:
  384. > : paulr@syma.sussex.ac.uk (Paul Russell) writes:
  385. > : >Am I right in thinking that there are no default
  386. > : >system AE coercion handlers ? Not even for such 
  387. > : >basic conversions as typeChar<->typeExtended ?
  388. > : >Is there a utility for displaying the installed
  389. > : >coercion handlers ?
  390. > : >Are there any available handlers for common
  391. > : >types, either as source or as an extension ?
  392. > : >//Paul
  393. > : There are default handlers for most numeric types to/from text and from
  394. > : alias to FSSpec. With AppleScript installed, there are many more coercion
  395. > : handlers available.
  396. > Thanks - I found the FKEY that displays the installed handlers and
  397. > although there is a motley assortment of coercion handlers, none
  398. > of the expected handlers for text<->float etc seem to be available.
  399. > This appears to be the case on several Macs that I have tried this on,
  400. > and I have also written a test program which calls AEGetCoercionHandler
  401. > which returns -1717 for just about any pair of types I try.
  402. > My best guess is that this is something to do with localisation - I am
  403. > wondering if the US version of the Apple Event Manager/Apple Script
  404. > checks the system version and doesn't install any handlers which might
  405. > be country-specific ? 
  406. > If the above is not the correct explanation then I'd be interested to
  407. > hear any other possible explanations for why the usual handlers aren't
  408. > available ?
  409. > //Paul
  410. > -- 
  411. > |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  412. > |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  413. > |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  414. > |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  415.  
  416. The FKEY displays the installed handlers, i.e. those handler installed
  417. using AEInstallXXX, but not the built-in handlers. The built-in handlers
  418. are listed in IM. The are built-in typeChar<->numericTypes. However they
  419. are not localized and are not meant for formating of numbers, they are
  420. more like what you expect to see in a debugger.
  421.  
  422. -- 
  423. /* Disclaimer: All statments and opinions expressed are my own */
  424. /* Edmund K. Lai                                               */
  425. /* Apple Computer, MS303-3A                                    */
  426. /* 20525 Mariani Ave,                                          */
  427. /* Cupertino, CA 95014                                         */
  428. /* (408)974-6272                                               */
  429. zW@h9cOi
  430.  
  431. +++++++++++++++++++++++++++
  432.  
  433. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  434. Date: 9 Mar 94 11:59:29 +1300
  435. Organization: University of Waikato, Hamilton, New Zealand
  436.  
  437. In article <isisCM2FpH.n03@netcom.com>, isis@netcom.com (Mike Cohen) writes:
  438. > paulr@syma.sussex.ac.uk (Paul Russell) writes:
  439. >
  440. >>Am I right in thinking that there are no default
  441. >>system AE coercion handlers ? Not even for such
  442. >>basic conversions as typeChar<->typeExtended ?
  443. >
  444. > There are default handlers for most numeric types to/from text and from
  445. > alias to FSSpec. With AppleScript installed, there are many more coercion
  446. > handlers available.
  447.  
  448. But one obvious one is missing: converting a pathname string to an alias or
  449. an FSSpec. I _always_ keep forgetting to prefix my pathnames with "file" or
  450. "alias"...
  451.  
  452. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  453. Info & Tech Services Division              fax: +64-7-838-4066
  454. University of Waikato            electric mail: ldo@waikato.ac.nz
  455. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  456.  
  457. +++++++++++++++++++++++++++
  458.  
  459. >From lai@apple.com (Ed Lai)
  460. Date: 10 Mar 1994 17:57:10 GMT
  461. Organization: Apple
  462.  
  463. In article <1994Mar3.134908.28390@syma.sussex.ac.uk>,
  464. paulr@syma.sussex.ac.uk (Paul Russell) wrote:
  465.  
  466. > John W. Baxter (jwbaxter@olympus.net) wrote:
  467. > : In article <1994Mar2.163154.19747@syma.sussex.ac.uk>,
  468. > : paulr@syma.sussex.ac.uk (Paul Russell) wrote:
  469. > : > Am I right in thinking that there are no default
  470. > : > system AE coercion handlers ? Not even for such 
  471. > : > basic conversions as typeChar<->typeExtended ?
  472. > : There are a bunch of coercions built in to the Apple Event Manager.  As it
  473. > : happens, typeChar<->typeExtended is one of them.  They are listed in Inside
  474. > : Mac: IAC in table 4-1, which occupies ALL of pages 4-43 and 4-44.
  475. > : There are more "exotic" ones built in, too, such as typeAppleEvent -->
  476. > : typeAppParameters (by far the easiest way to build THAT monster).
  477. > Thanks for the above and the rest of your comments - it looks like I
  478. > have some sort of problem. I tried writing a small program which just
  479. > calls AEGetCoercionHandler for a few different types and I get a -1717
  480. > for everything I've tried. I have Apple Event Manager 1.0.1 and
  481. > AppleScript 1.0 installed and am running System 7.1. I think both
  482. > Apple Event Manager 1.0.1 and AppleScript 1.0 may be out of date
  483. > by now so I'll have a dig through the developer CD's and see if
  484. > I can find something newer.
  485. > //Paul
  486. > -- 
  487. > |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  488. > |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  489. > |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  490. > |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  491.  
  492. AEGetCoercionHandler just returns whether an XXXX->YYYY coercion handler
  493. has
  494. been installed, it does not really tell you if a particular coercion
  495. exists.
  496. Built-in handler does not have a fixed address since the PACK can be
  497. relocated
  498. so the address cannot be returned. And if XXXX->YYYY coercion is handled by
  499. the ****->YYYY coercion handler, AEM has no idea that XXXX->YYYY can or
  500. cannot be done through ****->YYYY. So the rule is that it strictly returns
  501. an XXXX->YYYY address if it exists, it is not meant to rule out the
  502. existence of the possibility of XXXX->YYYY coercion.
  503.  
  504.  
  505. -- 
  506. /* Disclaimer: All statments and opinions expressed are my own */
  507. /* Edmund K. Lai                                               */
  508. /* Apple Computer, MS303-3A                                    */
  509. /* 20525 Mariani Ave,                                          */
  510. /* Cupertino, CA 95014                                         */
  511. /* (408)974-6272                                               */
  512. zW@h9cOi
  513.  
  514. +++++++++++++++++++++++++++
  515.  
  516. >From jonpugh@netcom.com (Jon Pugh)
  517. Date: Sat, 12 Mar 1994 07:19:44 GMT
  518. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  519.  
  520. Lawrence D'Oliveiro, Waikato University (ldo@waikato.ac.nz) wrote:
  521.  
  522. > But one obvious one is missing: converting a pathname string to an alias or
  523. > an FSSpec. I _always_ keep forgetting to prefix my pathnames with "file" or
  524. > "alias"...
  525.  
  526. This is done and working as part of Jon's Commands 1.1.  Interested in beta
  527. testing?
  528.  
  529. Jon
  530.  
  531.  
  532. ---------------------------
  533.  
  534. >From gjw2824@hertz.njit.edu (Greg Weston)
  535. Subject: ARGH!!! Whamwhamwham!! (DialogSelect stuff)
  536. Date: 5 Mar 94 19:58:17 GMT
  537. Organization: New Jersey Institute of Technology, Newark, New Jersey
  538.  
  539. Howdy, folks. I've been playing with everyone's favorite UI addition:
  540. Floating Windows. I've gotten them to work smoothly and cleanly, and
  541. they interact fine with normal windows and dialogs (modal or not). The
  542. only problem is within a pair of cute little routines called
  543. IsDialogEvent and DialogSelect. They don't like having a (floating)
  544. window in front of the Dialog they're working with. 
  545.  
  546. So, I re-wrote them. (Cough. Embarrased grin.) Still no problem. I'm
  547. left with one teensy little problem:
  548. How in the blazes does DialogSelect do its magic when you have
  549. multiple editTexts in a dialog and either click in a non-current one
  550. or press Tab?!?!
  551.  
  552. On that topic, IM is silent, and I can't figure out how to
  553. successfully pull off the swap with what they give you. Any thoughts,
  554. suggestions, or even polite chuckles would be appreciated.
  555.     Thanks,
  556.         Greg
  557.  
  558. +++++++++++++++++++++++++++
  559.  
  560. >From cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine)
  561. Date: Mon, 07 Mar 1994 10:31:52 -0800
  562. Organization: Ministry of Environment, Lands & Parks
  563.  
  564. In article <1994Mar5.195817.28298@njitgw.njit.edu>, gjw2824@hertz.njit.edu
  565. (Greg Weston) wrote:
  566.  
  567. > Howdy, folks. I've been playing with everyone's favorite UI addition:
  568. > Floating Windows. I've gotten them to work smoothly and cleanly, and
  569. > they interact fine with normal windows and dialogs (modal or not). The
  570. > only problem is within a pair of cute little routines called
  571. > IsDialogEvent and DialogSelect. They don't like having a (floating)
  572. > window in front of the Dialog they're working with. 
  573. > So, I re-wrote them. (Cough. Embarrased grin.) Still no problem. I'm
  574. > left with one teensy little problem:
  575. > How in the blazes does DialogSelect do its magic when you have
  576. > multiple editTexts in a dialog and either click in a non-current one
  577. > or press Tab?!?!
  578. > On that topic, IM is silent, and I can't figure out how to
  579. > successfully pull off the swap with what they give you. Any thoughts,
  580. > suggestions, or even polite chuckles would be appreciated.
  581. >     Thanks,
  582. >         Greg
  583.  
  584. One solution the new IM suggests instead of using dialog Select, you can
  585. use a custom routing to take a look at what kind of window the event
  586. occured in and then process the event that way.
  587.  
  588. Very usefull if you're dealing with modeless and movableModal Dialogs.
  589.  
  590. Source: IM Macintosh Toolbox Essentials, ch. 6 Dialog Manager.
  591.  
  592. -- 
  593. =========================================================================
  594. Carl B. Constantine                      B.C. Environment, Lands & Parks
  595. End-User Support Analyst                 CCONSTAN@epdiv1.env.gov.bc.ca
  596.  
  597. +++++++++++++++++++++++++++
  598.  
  599. >From Steve Bryan <sbryan@maroon.tc.umn.edu>
  600. Date: Tue, 8 Mar 1994 15:37:06 GMT
  601. Organization: Sexton Software
  602.  
  603. In article <1994Mar5.195817.28298@njitgw.njit.edu> Greg Weston,
  604. gjw2824@hertz.njit.edu writes:
  605. >How in the blazes does DialogSelect do its magic when you have
  606. >multiple editTexts in a dialog and either click in a non-current one
  607. >or press Tab?!?!
  608.  
  609.  I can't tell exactly how far along you are in this project but if you
  610. haven't taken a look at the DialogRecord structure you should do so now
  611. (I know, you probably have). 
  612. DialogRecord = record
  613.     window: WindowRecord;
  614.     items: Handle;
  615.     textH: TEHandle;
  616.     editField: Integer;
  617.     editOpen: Integer;
  618.     aDefItem: Integer;
  619. end;
  620. You need to manipulate the textH and editField variables. EditField
  621. points to the current text item in the linked list starting at items. Of
  622. course you have to update the current text item before setting up textH
  623. for the new text item. I thought there was some fairly useful information
  624. about this stuff in Inside Mac Volume I. My volume I is at home so I
  625. can't check but try looking there.
  626.  
  627. +++++++++++++++++++++++++++
  628.  
  629. >From u9119523@sys.uea.ac.uk (Graham Cox)
  630. Date: Wed, 9 Mar 1994 17:01:47 GMT
  631. Organization: School of Information Systems, UEA, Norwich
  632.  
  633. In article <cconstan-070394103153@eusacbc.env.gov.bc.ca>,
  634. cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine) wrote:
  635.  
  636. > In article <1994Mar5.195817.28298@njitgw.njit.edu>, gjw2824@hertz.njit.edu
  637. > (Greg Weston) wrote:
  638. > > Howdy, folks. I've been playing with everyone's favorite UI addition:
  639. > > Floating Windows. I've gotten them to work smoothly and cleanly, and
  640. > > they interact fine with normal windows and dialogs (modal or not). The
  641. > > only problem is within a pair of cute little routines called
  642. > > IsDialogEvent and DialogSelect. They don't like having a (floating)
  643. > > window in front of the Dialog they're working with. 
  644. > > 
  645. > > So, I re-wrote them. (Cough. Embarrased grin.) Still no problem. I'm
  646. > > left with one teensy little problem:
  647. > > How in the blazes does DialogSelect do its magic when you have
  648. > > multiple editTexts in a dialog and either click in a non-current one
  649. > > or press Tab?!?!
  650. > > 
  651. [SNIP!]
  652.  
  653.  
  654. If your question is how does it switch from one field to another, then I
  655. can answer!
  656.  
  657. In the DIALOGRECORD is a field which contains the ID number of the current
  658. editable item. When you hit tab, this is incremented and GetDItem called to
  659. see if the resulting item is an edit field, if not, it increments until it
  660. finds one or until the last item is found, at which point it starts over
  661. from item 1. When it finds an edit field item, it retrieves the text from
  662. the current one and stashes it into the item list as that item's string,
  663. then installs the text from the new one into the teRecord using TESetText,
  664. then selects it with TESetSelect, or if it was a click, calls TEClick. The
  665. DialogRecord also contains the teHandle.
  666.  
  667. The DialogRecord itself is documented in IM, though this sequence of events
  668. isn't- I had to figure this out for myself once when trying to do something
  669. along the same lines as you.
  670.  
  671. You can get the dialog record by casting the DialogPtr to type DialogPeek.
  672.  
  673. Hope this helps!
  674.  
  675.  
  676. > =========================================================================
  677. > Carl B. Constantine                      B.C. Environment, Lands & Parks
  678. > End-User Support Analyst                 CCONSTAN@epdiv1.env.gov.bc.ca
  679.  
  680. - ------------------------------------------------------------------------
  681. Love & BSWK, Graham
  682.  
  683. -Everyone is entitled to their opinion, no matter how wrong they may be...
  684. - ------------------------------------------------------------------------
  685. - ------------------------------------------------------------------------
  686. Love & BSWK, Graham
  687.  
  688. -Everyone is entitled to their opinion, no matter how wrong they may be...
  689. - ------------------------------------------------------------------------
  690.  
  691. +++++++++++++++++++++++++++
  692.  
  693. >From qsi@NU91.wlink.nl (Peter Kocourek)
  694. Date: Tue, 08 Mar 1994 20:55:13 +0100
  695. Organization: (none)
  696.  
  697. Greg Weston wrote in a message on 05 Mar 94 to All
  698.  
  699.  GW> Howdy, folks. I've been playing with everyone's favorite UI 
  700.  GW> addition: Floating Windows. I've gotten them to work smoothly 
  701.  GW> and cleanly, and they interact fine with normal windows and 
  702.  GW> dialogs (modal or not). The only problem is within a pair of 
  703.  GW> cute little routines called IsDialogEvent and DialogSelect. 
  704.  GW> They don't like having a (floating) window in front of the 
  705.  GW> Dialog they're working with.
  706.  GW>  So, I re-wrote them. (Cough. Embarrased grin.) Still no problem. I'm   
  707.  GW> left with one teensy little problem: How in the blazes does 
  708.  GW> DialogSelect do its magic when you have multiple editTexts in a
  709.  GW> dialog and either click in a non-current one or press Tab?!?! 
  710.  
  711. These two issues are separate from one another. Handling Tab presses is far
  712. easier than getting the mouseclick-induced editText change right. In fact, I
  713. haven't been able to get my own routines to do this properly. I was writing my
  714. own replacements for DialogSelect (to handle movable modals and modeless
  715. dialogs, with enhancements) and bumped into this problem. I tried all sorts of
  716. things with the TERecord, but I wasn't able to get the swap done cleanly.
  717.  
  718. So I cheated. :-) In my generic mouseDown-handling procedure (within my
  719. DialogSelect replacement), I first check to see where the mouseDown occurred.
  720. If it is in an editText field, I check whether it's the currently active
  721. text-input-capable [TIC, my shorthand] item, and in that case a simple TEClick
  722. call will take care of everything. If it is not the active TIC item (you have
  723. to keep track of this separately), and the currently active TIC is not an
  724. editText item, I call the deactivate function for the TIC; this is usually a
  725. custom routine for userItems which contain lists, for instance. One aesthetic
  726. problem with this is, that userItems don't have refCons, so that storing the
  727. ProcPtr's for userItem service routines is a bit cumbersome. Anyway, once your
  728. previously active TIC item is deactivated, you can activate manually the
  729. TERecord, and call TEClick.
  730. If, however, the active TIC item is an editText item, you'll have to "cheat".
  731. Having found no way doing the transition from one editText item to another
  732. cleanly, I simply call the real DialogSelect at that point. Note that I only do
  733. this when I have determined unambiguously, that the action to be taken is
  734. switching from one editText item to anohter.
  735.  
  736. As for handling Tabs, the situation is a bit easier. You have to find the next
  737. TIC item in your dialog (or the previous one, if the user pressed shift-Tab),
  738. and handle the deactivating and activating as above. The one thing that makes
  739. it doable without "cheating", is that you don't have to place the caret
  740. anywhere within the text of the next editText item (this was causing my
  741. problems), but you either select the entire text, if there is any, or you place
  742. just a caret, if there isn't. I'll include my source code where I do this.
  743. Parts of the code are specific to my implementation. For instance, I store a
  744. struct via a Handle in the window refCon. This struct contains lots of
  745. information about the dialog; you'll have to adapt it to your own needs. You
  746. will have to provide the CanAcceptText and ActivateItem functions for your own
  747. userItems.
  748. (sorry about the formatting)
  749.  
  750. /*************************************************************************************
  751.  * Somehow I'm not sure I should be doing this... requires too much thinking.
  752.  * CycleKeyBoardInput is a generic routine that will find and activate the next
  753. (or
  754.  * previous) item in the DITL that can accept keyDown events. To do this, it
  755. needs:
  756.  *  + a DialogPtr, to indicate in which dialog to look, and to get at the
  757. WIHandle.
  758.  *  + a Boolean isShiftPressed, to determine whether to search forward or
  759. backward in
  760.  *      the DITL
  761.  *  + a pointer to a function, that returns a Boolean. If this function,
  762. CanAcceptText,
  763.  *    returns TRUE, then the userItem (passed as a short to CanAcceptText) can
  764. accept
  765.  *    keyDown events. This function should be declared along with the other
  766. specific
  767.  *    functions for this dialog (as in AddressesDialog.c)
  768.  *  + another pointer to a function, that will either activate or deactivate a
  769. userItem
  770.  *    in the DITL, that can accept text. {De}Activating editText items is done
  771. here.
  772.  *
  773.  ************************************************************************************/
  774.  
  775. void CycleKeyboardInput(DialogPtr dPtr, Boolean isShiftPressed, 
  776.         Boolean (*CanAcceptText)(short), void (*ActivateItem)(WindowInfoHandle,
  777. short, Boolean))
  778.  
  779. {
  780.     WindowInfoHandle aWIHandle;          /* my own struct with info */
  781.     short    numItems, activeItem, queryItem, iType;
  782.  
  783.     aWIHandle = (WindowInfoHandle)GetWRefCon(dPtr);
  784.     activeItem = (**aWIHandle).activeItem; /* keeping track of the active TIC */
  785.     queryItem = activeItem + (isShiftPressed ? -1 : 1);
  786.     numItems = CountDITL(dPtr); 
  787.  
  788.     while (queryItem != activeItem)        /* check to see if we're back where we
  789. started */
  790.     {
  791.         if (queryItem == 0)                        /* handle rollover */
  792.             queryItem = numItems;
  793.         else if (queryItem == numItems+1)
  794.             queryItem = 1;
  795.             
  796.         GetDItem(dPtr, queryItem, &iType, &workHandle, &workRect);    /* get item info
  797. */
  798.         if (iType == editText)                                    /* if editText, we're finished */
  799.             break;
  800.         if (iType == userItem && CanAcceptText(queryItem))            /* same for userItem */
  801.             break;
  802.         
  803.         isShiftPressed ? queryItem-- : queryItem++;        /* get next item to query */
  804.     
  805.     }
  806.     
  807.     if (queryItem != activeItem)        /* found a new one? */
  808.     {
  809.         short aType;
  810.         
  811.         GetDItem(dPtr, activeItem, &aType, &workHandle, &workRect);
  812.         if (aType == userItem)
  813.             ActivateItem(aWIHandle, activeItem, FALSE);        /* deactivate currently active
  814. user item */
  815.         
  816.         
  817.         if (iType == editText)
  818.         {
  819.             SelIText(dPtr, queryItem, 0, 32767);    /* select new editText item */
  820.             workTEHandle = ((DialogPeek)dPtr)->textH;
  821.         }
  822.         else if (iType == userItem)
  823.         {
  824.             if (aType == editText)        /* was previously active item an editText? */
  825.                 TEDeactivate(((DialogPeek)dPtr)->textH);
  826.             ActivateItem(aWIHandle, queryItem, TRUE); /* select new userItem */    
  827.             workTEHandle = NIL;
  828.         }
  829.     
  830.         (**aWIHandle).activeItem = queryItem;
  831.         UpdateEditMenus(workTEHandle, kSystemTE);     /* my own service proc */
  832.         
  833.     }
  834. }
  835.  
  836. I hope you can make some sense out of all this. :-) Additional notes: CountDITL
  837. is System 7 specific (may come with CTB under System 6), but I don't do System
  838. 6 anymore. An example of an ActivateItem function would be for a list to draw a
  839. border around the list, to alert the user that keypresses will go to the list
  840. (to select a cell in the list).
  841.  
  842.  GW> On that topic, IM is silent, and I can't figure out how to 
  843.  GW> successfully pull off the swap with what they give you. Any 
  844.  GW> thoughts, suggestions, or even polite chuckles would be appreciated. 
  845.  
  846. <chuckle, polite> :-)
  847.  
  848.  
  849. YHS:QSI!
  850.  
  851.  
  852. +++++++++++++++++++++++++++
  853.  
  854. >From gjw2824@hertz.njit.edu (Greg Weston)
  855. Date: 10 Mar 94 20:38:09 GMT
  856. Organization: New Jersey Institute of Technology, Newark, New Jersey
  857.  
  858. Well, I had three people respond, each with different suggestions, and
  859. got it working with the first one. I'd like to thank Steve Bryan, Carl
  860. Constantine, and Simon Ward for their advice. I had looked through the
  861. IM vol 1 stuff pretty carefully, but the mechanics of the manipulation
  862. really were sketchy. My NIM is 100+ miles away, so I didn't have that
  863. to look through. I have a solution that works quite well, though, and
  864. I'm very happy with the finished product. Thank you kindly, and y'all
  865. will probably see a submission to the standard archives soon.
  866.     Greg
  867.  
  868. ---------------------------
  869.  
  870. >From ejohnson@netcom.com (Eric Johnson)
  871. Subject: An offering: Assembly language code for a high speed copybits
  872. Date: Fri, 18 Mar 1994 07:50:48 GMT
  873. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  874.  
  875. About two weeks ago, I had mentioned that I had written some assembly
  876. language code that could beat copybits given certain assumptions.  A
  877. number of people (Alex Metcalf and David Wareing) had asked me to send
  878. them some samples.  I was going to write up some demo code with it,
  879. but never got around to it due to work obligations.
  880.  
  881. A few days ago, I sent David an email message with some and a length
  882. explanation.  I figured that maybe everyone else could benefit from
  883. the email to.  Keep in mind that the following code was my first real
  884. whack at some high speed copybits.  I may be breaking a few rules, or
  885. doing bad Mac programmer things.  So USE IT AT YOUR OWN RISK.
  886.  
  887. I believe further enhancements can be made to it, especially given the
  888. wide spread prominence of the 030 and 040.  When I first wrote it, the
  889. 020 was in much more common use.
  890.  
  891. This code has evolved into a copybits that will do some very fast
  892. masking.  I had used it for a graphics engine that would display
  893. things at a perspective.  Where each icon was a perspective block, if
  894. you will.  Thus masking was needed.  It looks quite sharp.  I can go
  895. over that code too, as well as the trick I put in for some fast
  896. masking.  As always, you pay for the speed.  It needs a bit of memory.
  897.  
  898. Let me know if this helps anyone.  Here is the message I sent to David
  899. Wareing. 
  900.  
  901. <------------->
  902.  
  903. David,
  904.  
  905. Okay, here's some code with some explanation off the top of my head.
  906.  
  907. This code was developed for a tile based adventure game that was never
  908. quite finished.  The graphics were a simple display consisting of
  909. 11x11 icons where each icon was a 24x24 cicn resource.  This type of
  910. display is identical to that of the old Ultima games on the Apple ][
  911. and old PC's.  And the more recent Zelda of Nintendo or Civilization
  912. on the Macintosh.
  913.  
  914. I initially wrote everything in C, and used PlotCIcon to place my color
  915. icons on the screen.  In found that to be too slow, because the Mac
  916. was constantly converting the colors in the resource to those
  917. available on the screen.  Hence the molases like quality.  So I said
  918. to myself, "Screw it, I'm going do it in assembly.".
  919.  
  920. Even though the code I'm including has been rewritten for a slightly
  921. more complex display, I'm giving this to you so you can follow the
  922. history of its development.  It should make more sense this way, and
  923. you'll see some room for improvements along the way.  I wrote this as
  924. a beginner Mac programmer, so I may be breaking some rules.
  925.  
  926. Let's first identify what slows down drawing to the screen.  In my
  927. case, I had a few mistakes.  The first one was using PlotCIcon.  The
  928. Mac was constantly converting the resource into the current colors
  929. available in the port.  That's all well and good, in fact that's quite
  930. nice of them.  But it slows things down a bit.
  931.  
  932. To get around this, I created an off screen window that would
  933. warehouse my icons.  The benefit is that the off screen window would
  934. have the same color table [CLUT, right?] so any transfer between an
  935. offscreen window and the main screen would be a trivial copy.  Thus,
  936. at start time, I painted each icon into the off screen to "coerce" it
  937. into the current system table.
  938.  
  939. Okay, so I did that.  I would then use copy bits to repaint my window.
  940. In my game, I have a two dimensional array with numbers indicating
  941. which icon goes at what location.  So, I would get the id number of
  942. the display icon, locate it in my off screen window [the palette of
  943. icons] and use copybits to get it to the window.
  944.  
  945. Well, that was better, but was still slower than I expected.  So, I
  946. got to thinking about how to speed things up.  The bottleneck in this
  947. case is copybits.  Sure, copybits is fairly fast, but I know a few
  948. things about my icons that it doesn't know.  They are all of the same
  949. width, and same height.  But how do I put this knowledge to good use?
  950.  
  951. Let's step back for a second and look at the Motorola architecture.
  952. When I wrote it, I decided to take advantage of the features found in
  953. the 68020's and later.  It really starts to do well in the 030.  We
  954. won't consider the 68000 because there's not much you can do for that
  955. chip.
  956.  
  957. The 680x0 has 8 32 bit data registers and 8 32 address registers.  You
  958. lose some of the address registers to the system, but all in all,
  959. there's some room to play around in.  The 68020 and later have some
  960. code cache and data caches to work with too.  In other words, you can
  961. have a loop fill up the instruction cache, and then the CPU can run
  962. faster because all of its code is in the cache.
  963.  
  964. It's this instruction cacheing that I take full advatange of.  In later
  965. developments of this code, I try to take advantage of the data cache.
  966. So, we need to write some assembly language code that will copy 24
  967. bytes at a time from 24 different parts of memory.  Remember, in this
  968. case, my icons are 24 bytes wide (24 pixels at 8 bits a pixel).  And
  969. the are 24 pixels high.  So, we've got 24 blocks of 24 pixels.  Each
  970. block starts at a slightly different memory location.
  971.  
  972. My code loops 24 times, one for each row of 24 bytes.  Thus, the code
  973. that copies each row lands in the instruction cache.  So, on each
  974. subsequent reitiration of the code, we are running strictly from the
  975. cache.  This gives us some good performance.  But there's one more
  976. feature too.
  977.  
  978. Most modern processors have a pipeline where the different parts of
  979. the CPU execute part of an instruction then hand it off to the next
  980. step.  It works identically to an assembly line where someone installs
  981. the engine and the next person installs the tires.  A new car always
  982. rolls off the line every so often even though it may take a bit for a
  983. car to travel the entire line.
  984.  
  985. The catch lies with branch instructions.  The CPU won't know if the
  986. branch should be taken until its evaluation is complete.  But, this
  987. means that the CPU won't necessarily be putting the right instructions
  988. in the pipeline.  It would be like producing a car that indicated the
  989. previous cars should be destroyed.  This wrecks efficiency.
  990.  
  991. To get around it, Motorola has provided an instruction, dbra, that
  992. serves as a hint.  dbra tells the CPU to branch if the contents of the
  993. data register are not zero.  It instructs the CPU to expect the branch
  994. and fill the pipeline with the instructions that would result if a
  995. branch takes place.
  996.  
  997. So, my loops gets two nice features going.  The instruction cache and
  998. it keeps the pipeline going too.  Pretty sweet, eh?
  999.  
  1000. My code works in two steps.  The first section is the prepatory work
  1001. for the loop.  I put as much stuff as I can into registers, because
  1002. adding and multiplying "in register" is much faster than from memory.
  1003. And the instructions are shorter, which means less space is taken up
  1004. in the instruction cache.
  1005.  
  1006. This point of putting stuff "in register" may seem anal, but remember,
  1007. we need to add some values at the end of each iteration of the loop
  1008. and keeping stuff as fast and small is good.
  1009.  
  1010. Now, let's go over the parameters to the code.
  1011.  
  1012. mySource points to the start of the off screen palette.
  1013. myDestination points to the start of the off screen drawing space.
  1014.  
  1015. xSource and ySource are the x,y coordinates of the pixel that
  1016. represents the upper left hand corner of the thing you wish copied.
  1017. Keep in mind that these are *PIXEL COORIDINATES* not icon coordinates.
  1018. Its up to you to find the start of the icon you wish copied in your
  1019. off screen palette of icons.  I suppose my code could do it.  I just
  1020. didn't bother.
  1021.  
  1022. xDestination and yDestination are the same xSource and ySource except
  1023. for the destination array.
  1024.  
  1025. iconSize should be your icon height minues one.  In my case, its 23.
  1026.  
  1027.  
  1028. int  MyCopyBits8(Ptr mySource, Ptr myDestination,
  1029.                  long int xSource, long int ySource,
  1030.                  long int xDestination, long int yDestination,
  1031.                  long int iconSize) {
  1032.   
  1033.   asm 68000 {
  1034.  
  1035.     /**
  1036.      ** We need to save the registers that we are going to clobber.
  1037.      **
  1038.      ** a1 starts out pointing to the top of the pallete, but it .
  1039.      ** will eventually end up pointing to the start of the source
  1040.      ** icon.  Same goes for a2.
  1041.      **
  1042.      ** d2 and d3 are a bit tricky to explain.  They are the row
  1043.      ** byte values for the source and destination.  A row byte
  1044.      ** value is the number of bytes required to jump down to the
  1045.      ** next row.  It needs to be a multiple of four else some
  1046.      ** Mac internals complain.  We use these values to find the
  1047.      ** real location of both icons.
  1048.      **
  1049.      **/
  1050.  
  1051.     movem.l    a1-a2/d0-d3, -(sp);    /* save the regs */
  1052.     move.l    mySource,a1;
  1053.     move.l    myDestination,a2;
  1054.     move.l    #0x0780,d2;    /* hard coded row bytes value */
  1055.     move.l    #0x0138,d3;    /* hard coded row bytes value */
  1056.  
  1057.     /**
  1058.      ** The following four lines find the real address of the source
  1059.      ** icon.  They do this by following a simple formula.
  1060.      **  real_source = base + y Position * row bytes for Src + x Pos
  1061.      ** This result is placed into a1 as mentioned before.
  1062.      **/
  1063.     
  1064.     move.l    ySource,d0;
  1065.     mulu    d2,d0;
  1066.     add.l    d0,a1;
  1067.     add.l    xSource,a1;
  1068.  
  1069.     /** We follow the same formula for the destination address **/
  1070.     
  1071.     move.l    yDestination,d0;
  1072.     mulu    d3,d0;
  1073.     add.l    d0,a2;
  1074.     add.l    xDestination,a2;
  1075.  
  1076.     /**
  1077.      ** The following will seem a bit weird.  Why subtract #20 from the
  1078.      ** row byte values?  Keep in mind that as we are copying from the
  1079.      ** source to the destination, we are changing our pointers 
  1080.      ** (marching them across the icon).  When we are finished copying,
  1081.      ** we need to add the rowBytes-20 to get to the first byte of the
  1082.      ** the next row.  Note that 20 is iconSize-3.  Yeah, that should be
  1083.      ** that way in the code.  Just never bothered to change it.
  1084.      **/
  1085.  
  1086.     sub.l    #20,d2;
  1087.     sub.l    #20,d3;
  1088.     move.l    iconSize,d0;
  1089.  
  1090.     /** END OF PREPARTORY WORK **/
  1091.  
  1092.     /** And now you're ready to start the copy of each row of bytes **/
  1093.     
  1094.     @1   ;
  1095.     move.l    (a1)+,(a2)+;  /** Note that we are increasing our **/
  1096.     move.l    (a1)+,(a2)+;  /** pointers as go along here.      **/
  1097.     move.l    (a1)+,(a2)+;  /** Also note that we copy four     **/
  1098.     move.l    (a1)+,(a2)+;  /** bytes at a crack.  And we do it **/
  1099.     move.l    (a1)+,(a2)+;  /** six times.  For 24 bytes!       **/
  1100.     move.l    (a1),(a2);
  1101.         
  1102.     add.l    d2,a1; /** We need to jump down to the start of **/
  1103.     add.l    d3,a2; /** first pixel in the next row.         **/
  1104.     dbra    d0,@1; /** Branch until we are done **/
  1105.       
  1106.     movem.l    (sp)+, a1-a2/d0-d3  /* restore the registers */
  1107.   }
  1108.         
  1109.   return(1);
  1110. }
  1111. -- 
  1112. Eric E Johnson
  1113. ejohnson@netcom.netcom.com   
  1114.  
  1115. ---------------------------
  1116.  
  1117. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1118. Subject: Animation speed: here we go again...
  1119. Date: Sat, 12 Mar 1994 10:14:53 GMT
  1120. Organization: Demon Internet
  1121.  
  1122.  
  1123.  
  1124.         Now that we've exhausted the previous "animation speed" thread,
  1125. it's time to start another. :-)
  1126.  
  1127.         Having got my game code to run (what I considered to be) extremely
  1128. fast on my LC475, I thought I'd give it a whirl on our IIsi. Oh no!
  1129. Extremely slow animation speed. I know that the IIsi has very slow video,
  1130. but what was running at 60fps on an LC475 surely wouldn't be reduced to
  1131. less than 10fps on a IIsi.
  1132.  
  1133.         One of the things I thought might be causing the problem was that I
  1134. still might be having problems matching colour tables between the GWorld
  1135. and the window on-screen. I'm creating a normal colour window, and making
  1136. it the size of the screen (0,0,640,480). I'm not changing its palette in
  1137. any way. Then I'm using NewGWorld with a pixel depth of 0, which is meant
  1138. to optimise CopyBits calls with the screen. It's also meant to use the
  1139. colour table info and screen depth of the deepest monitor intercepting the
  1140. given rectangle. Since I've only got one monitor, this shouldn't be the
  1141. problem.
  1142.  
  1143.         However, response still seems to be unreasonbly sluggish on the
  1144. IIsi: whether its in gray scale or colour, the speed is disappointing.
  1145.  
  1146.         I believe Andrew Welch (hope I spelt your name right) reads this
  1147. area regularly: for Maelstrom, what is the animation speed like on low end
  1148. '030 Macs? I know you use heavily optimised assembler for your animation,
  1149. but I don't think that what I'm doing (CopyBits) should case such a
  1150. dramatic difference in animation speed. Is there any way to make CopyBits
  1151. completely ignore the colour table differences?
  1152.  
  1153.         Interesting ideas and suggestions are always appreciated.
  1154.  
  1155.  
  1156.  
  1157.         Alex
  1158.  
  1159. --
  1160. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  1161.  
  1162. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  1163. AppleLink:              alex@metcalf.demon.co.uk@internet#
  1164. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  1165. Delphi:                 alex@metcalf.demon.co.uk@inet#
  1166. FirstClass:             alex@metcalf.demon.co.uk,Internet
  1167. Fax (UK):               (0570) 45636
  1168. Fax (US / Canada):      011 44 570 45636
  1169.  
  1170. +++++++++++++++++++++++++++
  1171.  
  1172. >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault)
  1173. Date: Tue, 15 Mar 1994 12:29:41 -0500
  1174. Organization: Motorola Codex
  1175.  
  1176. In article <alex-120394101542@metcalf.demon.co.uk>,
  1177. alex@metcalf.demon.co.uk (Alex Metcalf) wrote:
  1178.  
  1179. >         However, response still seems to be unreasonbly sluggish on the
  1180. > IIsi: whether its in gray scale or colour, the speed is disappointing.
  1181.  
  1182. It sounds like you're okay with your color tables and CopyBits.
  1183.  
  1184. You might be running into a hardware problem.  There is no separate VRAM
  1185. for video on the IIsi (or IIci).  The IIsi has 1 MB on the motherboard, a
  1186. portion of which it uses as video RAM.   Not that I've investigated this,
  1187. but I remember reading that if the disk cache is boosted to occupy the
  1188. majority of motherboard RAM, then the video driver uses the SIMMs instead
  1189. and because the SIMM RAM doesn't have to deal with a bank switch wait you
  1190. can get approx. a 30% speed increase. 
  1191.  
  1192. The unfortunate part about this is that it's not really software
  1193. controllable - it's sort of up to the user.
  1194.  
  1195. Chris
  1196. -- 
  1197. #include <UsualLegalDisclaimers.h>
  1198.  
  1199. ---------------------------
  1200.  
  1201. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1202. Subject: Animation speed: improvement!
  1203. Date: Sun, 6 Mar 1994 23:16:59 GMT
  1204. Organization: Demon Internet
  1205.  
  1206.  
  1207.         I discovered something quite interesting this afternoon, which has
  1208. almost doubled the speed of the sprite animation in my game.
  1209.  
  1210.         Just a quick recap: my game copies the background (behind the
  1211. sprites) to a gworld, copies the sprites the same gworld, and then copies
  1212. that rectangle to the screen. In all, I was using 5 CopyBits for the
  1213. background, 5 CopyMasks for the sprites, and 5 CopyBits for copying to the
  1214. screen.
  1215.  
  1216.         Someone originally suggested that I combined all the rectangles
  1217. into a region and do a single CopyBits call. However, it turned out to be
  1218. slower! Go figure. I guess the individual CopyBits calls outstrip the
  1219. RectRgn and UnionRgn calls.
  1220.  
  1221.         This afternoon, I thought I'd give it another shot, in case I'd
  1222. missed something (or done a goofy error which was slowing things down).
  1223. This time, for no particular reason, I chose to combine the rectangles for
  1224. my CopyBits calls to the screen, and only do the single CopyBits call.
  1225.  
  1226.         I gave it a go and... WHOAH! Unbelievable speed increase (almost
  1227. 200%, 60 fps). It seems that CopyBits calls have much more overhead when
  1228. copying to the screen rather than copying between offscreen gworlds. I
  1229. guess this is because it checks screen depth, colour tables, etc. etc.
  1230.  
  1231.         To give you an idea of the speed increase: with the extra "time" I
  1232. had in my game loop, I was able to add another 4 sprites to the screen,
  1233. resulting in another 4 CopyBits calls and 4 CopyMask calls. Even then, it
  1234. was still faster than when I was using individual CopyBits calls to the
  1235. screen!
  1236.  
  1237.         So, I've found that the fastest way (with normal QuickDraw
  1238. routines) to make my animation work is to use individual CopyBits calls for
  1239. sprites between GWorlds, and then a single CopyBits call when it's all
  1240. ready to come to the screen.
  1241.  
  1242.         Here's my code snippet for the copy-to-screen, where gWorldRect is
  1243. 0,0,640,480 (full screen). I guess I don't need the second SetEmptyRgn
  1244. call.
  1245. (I use "t" to denote local variables).
  1246.  
  1247.  
  1248. // ------
  1249.  
  1250.         SetEmptyRgn (tCopyRgn);
  1251.         SetEmptyRgn (tRectRgn);
  1252.         
  1253.         tObject = gFirstObject;
  1254.         while (tObject != nil)
  1255.         {
  1256.                 if (!tObject->fVisible)
  1257.                 {
  1258.                         tObject = (GameObject) tObject->fNextObject;
  1259.                         continue;
  1260.                 }
  1261.                 
  1262.                 RectRgn (tRectRgn, &tObject->fAnimEnclosureRect);
  1263.                 UnionRgn (tRectRgn, tCopyRgn, tCopyRgn);
  1264.                 
  1265.                 tObject = (GameObject) tObject->fNextObject;
  1266.         }
  1267.         CopyBits ((BitMap *) *tPixMap[3], (BitMap *)
  1268. &gGameWindow->portPixMap,
  1269.                 &gWorldRect, &gWorldRect, srcCopy, tCopyRgn);
  1270.  
  1271. // ------
  1272.  
  1273.  
  1274.         On a slightly different topic: thanks to some code by Francis
  1275. (Francis H Schiffer 3rd), I was able to test my game loop to see where the
  1276. time was being used up. I knew that the copying of graphics takes up quite
  1277. a lot of time, but I'd never imagined that it tool 98% of the time!
  1278. Needless to say, that is what inspired me to have another go at improving
  1279. the CopyBits speed...
  1280.  
  1281.         Thanks again to all those who have given suggestions and code
  1282. snippets.... they've all been very useful (or at least, interesting!).
  1283.  
  1284.       
  1285.         Alex
  1286.  
  1287. --
  1288. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  1289.  
  1290. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  1291. AppleLink:              alex@metcalf.demon.co.uk@internet#
  1292. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  1293. Delphi:                 alex@metcalf.demon.co.uk@inet#
  1294. FirstClass:             alex@metcalf.demon.co.uk,Internet
  1295. Fax (UK):               (0570) 45636
  1296. Fax (US / Canada):      011 44 570 45636
  1297.  
  1298. +++++++++++++++++++++++++++
  1299.  
  1300. >From u9119523@sys.uea.ac.uk (Graham Cox)
  1301. Date: Mon, 7 Mar 1994 11:23:35 GMT
  1302. Organization: School of Information Systems, UEA, Norwich
  1303.  
  1304. In article <alex-060394231740@metcalf.demon.co.uk>,
  1305. alex@metcalf.demon.co.uk (Alex Metcalf) wrote:
  1306.  
  1307. >         I discovered something quite interesting this afternoon, which has
  1308. > almost doubled the speed of the sprite animation in my game.
  1309. [SNIP!]
  1310.  
  1311. I also read somewhere that CopyBits with a mask region parameter is faster
  1312. than CopyMask- you might want to try this and see if it's true.
  1313.  
  1314. - ------------------------------------------------------------------------
  1315. Love & BSWK, Graham
  1316.  
  1317. -Everyone is entitled to their opinion, no matter how wrong they may be...
  1318. - ------------------------------------------------------------------------
  1319.  
  1320. +++++++++++++++++++++++++++
  1321.  
  1322. >From Tony Myles <tony.myles@3do.com>
  1323. Date: 7 Mar 1994 21:45:34 GMT
  1324. Organization: The 3DO Company
  1325.  
  1326. In article <alex-060394231740@metcalf.demon.co.uk> Alex Metcalf,
  1327. alex@metcalf.demon.co.uk writes:
  1328. [stuff deleted]
  1329. >        So, I've found that the fastest way (with normal QuickDraw
  1330. >routines) to make my animation work is to use individual CopyBits calls
  1331. for
  1332. >sprites between GWorlds, and then a single CopyBits call when it's all
  1333. >ready to come to the screen.
  1334. [stuff deleted]
  1335.  
  1336.  
  1337. Hey, thats cool. Hmm, just out of curiosity, what kind of Mac are you
  1338. running this on? I think I tried this a long time ago on a Q800, and it
  1339. was still slower than individual CopyBits calls to the screen. I'll have
  1340. to try it again though, I can't remember if I did it quite the way you
  1341. describe.
  1342.  
  1343. ...Tony
  1344. - ---------------------------------------------
  1345. Tony Myles             work: tony.myles@3do.com
  1346. The 3DO Company        home: suiryu@aol.com
  1347.  
  1348. +++++++++++++++++++++++++++
  1349.  
  1350. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1351. Date: Tue, 8 Mar 1994 13:38:19 GMT
  1352. Organization: Demon Internet
  1353.  
  1354. In article <2lg79u$lp8@mac_serv.3do.COM>, Tony Myles <tony.myles@3do.com>
  1355. wrote:
  1356.  
  1357. > In article <alex-060394231740@metcalf.demon.co.uk> Alex Metcalf,
  1358. > alex@metcalf.demon.co.uk writes:
  1359. > [stuff deleted]
  1360. > >        So, I've found that the fastest way (with normal QuickDraw
  1361. > >routines) to make my animation work is to use individual CopyBits calls
  1362. > for
  1363. > >sprites between GWorlds, and then a single CopyBits call when it's all
  1364. > >ready to come to the screen.
  1365. > [stuff deleted]
  1366. > Hey, thats cool. Hmm, just out of curiosity, what kind of Mac are you
  1367. > running this on?
  1368. > <snip>
  1369.  
  1370.         I'm running this on an LC475. I believe I've got all the colour tables
  1371. matched up correctly, and the source and destination rectangles are the
  1372. same (and the bit depths).
  1373.  
  1374.  
  1375.      Alex
  1376.  
  1377. --
  1378. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  1379.  
  1380. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  1381. AppleLink:              alex@metcalf.demon.co.uk@internet#
  1382. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  1383. Delphi:                 alex@metcalf.demon.co.uk@inet#
  1384. FirstClass:             alex@metcalf.demon.co.uk,Internet
  1385. Fax (UK):               (0570) 45636
  1386. Fax (US / Canada):      011 44 570 45636
  1387.  
  1388. ---------------------------
  1389.  
  1390. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1391. Subject: Animation speed: more info
  1392. Date: Thu, 3 Mar 1994 00:25:29 GMT
  1393. Organization: Demon Internet
  1394.  
  1395.  
  1396.  
  1397.         Thanks to those who sent replies to me about improving the
  1398. animation speed in my game.
  1399.  
  1400.         I thought I'd be a little more specific in this description about
  1401. exactly what I'm doing, and (as always) I appreciate any feedback.
  1402.  
  1403.         I have an arcade game which I would like to run at 30 fps on a
  1404. 68030 Mac or better. It currently DOES run at 30 fps on my LC475, but only
  1405. just, and since that's on a 68LC040, I don't stand much chance of 30 fps on
  1406. an 030!
  1407.  
  1408.         In my game, there are 5 or 6 sprites always on the screen, each of
  1409. them 24 x 24 pixels in size. There are a number of calculations that I do
  1410. with them each time through my 2 tick "loop", but I'm assuming that I can
  1411. get the most speed increase by improving my animation code.
  1412.  
  1413.         I have four (yeah, four) offscreen gworlds, three of them in 8 bit
  1414. and 1 in 1 bit. I'll call the 1 bit one the "mask world", and the other
  1415. ones worlds "one", "two", and "three".
  1416.  
  1417.         In world one, I have all my sprite animations, placed there from a
  1418. PICT resource. In the mask world, I have the masks for the sprites, all
  1419. with exactly the same rectangles as the ones in world one.
  1420.  
  1421.         In world two, I have the background. I'm using world 3 as the
  1422. destination world for preparing to copy to the screen window.
  1423.  
  1424.         Every time through my loop, I first copy all the background rects
  1425. to world three, each one covering the previous location and the next
  1426. location of a sprite. This is done with a CopyBits call between worlds.
  1427. Then, I use CopyMask to copy the sprites (from world one and the mask
  1428. world) on to the background (world three). Finally, I copy each of the
  1429. background rects onto the screen, again using CopyBits.
  1430.  
  1431.         So in summary: I make 6 CopyBits calls between worlds, 6 CopyMask
  1432. calls between worlds, and 6 CopyBits calls from the world to the screen.
  1433. The rectangles being copied are no more than 32 x 32.
  1434.  
  1435.         How can I speed this up? I know that assembly programming would be
  1436. useful here, but hacking up an assembler copy between gworlds is a new
  1437. project to me. I would like to get the animation up to a speed where I can
  1438. do 30 fps on a 20mhz 68030, with slow screen redraw (a.k.a. our Mac IIsi).
  1439.  
  1440.         Thanks in advance for any help you can give me.
  1441.  
  1442.         
  1443.  
  1444.         Alex
  1445.  
  1446. --
  1447. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  1448.  
  1449. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  1450. AppleLink:              alex@metcalf.demon.co.uk@internet#
  1451. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  1452. Delphi:                 alex@metcalf.demon.co.uk@inet#
  1453. FirstClass:             alex@metcalf.demon.co.uk,Internet
  1454. Fax (UK):               (0570) 45636
  1455. Fax (US / Canada):      011 44 570 45636
  1456.  
  1457. ---------------------------
  1458.  
  1459. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  1460. Subject: Animation: the story continues...
  1461. Date: Sun, 6 Mar 1994 00:45:45 GMT
  1462. Organization: Demon Internet
  1463.  
  1464.  
  1465.         Just a quick update on my original question about speeding up
  1466. animation in my game code.
  1467.  
  1468.         Thanks to all those who gave suggestions for speeding things up:
  1469. I'm sorry I haven't had a chance to reply to each of you individually, but
  1470. I've had a huge amount of email (about 50 messages a day) and I'm finding
  1471. it hard to keep up. Along side this game, I'm working on about 5 or 6
  1472. different HyperCard external projects, and that mail (together with regular
  1473. newsletters and listserv discussions) makes life quite busy!
  1474.  
  1475.         Anyway, here are a few of the suggestions I've tried:
  1476.  
  1477.  
  1478. o  A suggestion was made that rather than CopyBits each of the sprites from
  1479. one world to another, I should combine them into a single region and make
  1480. only one CopyBits call.
  1481.  
  1482.    Here's the way I was doing it before:
  1483.  
  1484.  ...
  1485.         tObject = gFirstObject;
  1486.         while (tObject != nil)
  1487.         {
  1488.                 if (!tObject->fVisible)
  1489.                 {
  1490.                         tObject = (AppObject) tObject->fNextObject;
  1491.                         continue;
  1492.                 }
  1493.                 
  1494.                 CopyBits ((BitMap *) *tPixMap[2], (BitMap *) *tPixMap[3],
  1495.                         &tObject->fAnimEnclosureRect,
  1496.                         &tObject->fAnimEnclosureRect, srcCopy, nil);
  1497.                 tObject = (AppObject) tObject->fNextObject;
  1498.         }
  1499.  ...
  1500.  
  1501.    And here's the way I tried doing it, using only a single CopyBits call.
  1502. gWorldRect is the enclosing rectangle for the gworld.
  1503.  
  1504.  ...
  1505.         SetEmptyRgn (gCopyRgn);
  1506.         
  1507.         tObject = gFirstObject;
  1508.         while (tObject != nil)
  1509.         {
  1510.                 if (!tObject->fVisible)
  1511.                 {
  1512.                         tObject = (AppObject) tObject->fNextObject;
  1513.                         continue;
  1514.                 }
  1515.                 RectRgn (gRectRgn, &tObject->fAnimEnclosureRect);
  1516.                 UnionRgn (gCopyRgn, gRectRgn, gCopyRgn);
  1517.                 
  1518.                 tObject = (AppObject) tObject->fNextObject;
  1519.         }
  1520.         CopyBits ((BitMap *) *tPixMap[2], (BitMap *) *tPixMap[3],
  1521.                 &gWorldRect, &gWorldRect, srcCopy, gCopyRgn);
  1522.  ...
  1523.  
  1524.  
  1525.    The second section of code being slower than the first!
  1526.  
  1527.  
  1528. o  Someone else had suggested that rather than do a CopyMask call, I could
  1529. do a CopyBits call with a region (apparently being 60% faster). However,
  1530. while the mask for CopyMask masks out the source, the region for CopyBits
  1531. masks out the destination. Therefore, unless I can change the position of a
  1532. region each time I copy a sprite to the screen, I'm not sure the region
  1533. param in CopyBits will help.
  1534.  
  1535.  
  1536.         Thanks again for all those who have helped out: further suggestions
  1537. are always welcomed. I've learned a whole lot more about CopyBits and
  1538. CopyMask now!
  1539.  
  1540.         Thanks,
  1541.  
  1542.  
  1543.         Alex
  1544.  
  1545. --
  1546. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  1547.  
  1548. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  1549. AppleLink:              alex@metcalf.demon.co.uk@internet#
  1550. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  1551. Delphi:                 alex@metcalf.demon.co.uk@inet#
  1552. FirstClass:             alex@metcalf.demon.co.uk,Internet
  1553. Fax (UK):               (0570) 45636
  1554. Fax (US / Canada):      011 44 570 45636
  1555.  
  1556. ---------------------------
  1557.  
  1558. >From mprince@mail.trincoll.edu (Matthew Prince)
  1559. Subject: Blank Screen?
  1560. Date: Wed, 2 Mar 1994 16:52:07 GMT
  1561. Organization: Trinity College
  1562.  
  1563. I'm curious what exactly I need to do to blank the entire screen.  When
  1564. I try to create a window that is the entire size of the GrayRgn I am
  1565. able to cover up everything but the menu bar.  Is there then a
  1566. hideMenuBar command or something?  Also, when I PaintRect the area
  1567. defined by the GrayRgn to black a strip about the width of and right
  1568. below the menu bar is left white.  Any help would be appreciated.
  1569.  
  1570. Matthew Prince
  1571. mprince@mail.trincoll.edu
  1572.  
  1573. +++++++++++++++++++++++++++
  1574.  
  1575. >From kenlong@netcom.com (Ken Long)
  1576. Date: Thu, 3 Mar 1994 03:53:58 GMT
  1577. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1578.  
  1579. Yes.  You hide your menuBar before you show your window.  That way the 
  1580. window is not 20 pixels down with the user's desktop textuer peeking over 
  1581. the top.
  1582.  
  1583. The "HideMenuBar" and "ShowMenuBar routines in NewShuttle 1.0d3 are about 
  1584. as common as they come.  I consulted 3 or 4 other working menu bar 
  1585. hide/show sources before finally deciding on that one.
  1586.  
  1587. That Shuttle source is kind of a cheapo.  It uses a "full screet window" 
  1588. as long as you use a 512 x 384 monitor.  Unless your window is based on 
  1589. screenBits.bounds, as apple points out, such specific sized main windows 
  1590. are user unfriendly.  But you also have to get fancy about positioning 
  1591. and/or sizing your window contents if you are going to make users with 
  1592. monitors over 14" happy, too.  But scaling your screen objects is not 
  1593. very viable - it usually makes them look odd.
  1594.  
  1595. You could do a monitor check and if it's larger than 14", don't hide the 
  1596. MBar and center the window.  Another trick, as in "Out of This World" is 
  1597. to have all black outside the window.  you could hide MBar, fill the rgn 
  1598. with black, and center your window within it.  That looks okay regardless 
  1599. of window size (wintin reason).  It that particular game, a click outside 
  1600. the action window updates the desktop, washing away the black.  A click 
  1601. back in the action window, blacks it out, again.  Nicely done.
  1602.  
  1603. There are probably more 14" monitors than any other.  The 12"s were 
  1604. popular when they first came out, but I wish I didn't get one.
  1605.  
  1606. Some people, if the program is thoroughly done, will make sets of sizes 
  1607. of program parts for different monitors.  The program would have to be 
  1608. worth it, and it would be done to increase the purchaser base potential.
  1609.  
  1610. Here's some hide/show MBar, in C:
  1611.  
  1612. RgnHandle mBarRgn;        // First we need to "get a holt of" the MBar.
  1613. short      *mBarHeightPtr;
  1614. short      oldMBarHeight;
  1615.  
  1616. void HideMenuBar (void) 
  1617. {
  1618.     Rect    mBarRect;
  1619.  
  1620.     GrayRgn = GetGrayRgn ();
  1621.     mBarHeightPtr = (short *)  0x0BAA;
  1622.     oldMBarHeight = *mBarHeightPtr;
  1623.     *mBarHeightPtr = 0;
  1624.     mBarRect = screenBits.bounds;
  1625.     mBarRect.bottom = mBarRect.top + oldMBarHeight;
  1626.     mBarRgn = NewRgn ();
  1627.     RectRgn (mBarRgn, &mBarRect);
  1628.     UnionRgn (GrayRgn, mBarRgn, GrayRgn);
  1629.     PaintOne (0L, mBarRgn);
  1630. }
  1631. void ShowMenuBar (void) 
  1632. {
  1633.     *mBarHeightPtr = oldMBarHeight;
  1634.     DiffRgn (GrayRgn, mBarRgn, GrayRgn);
  1635.     DisposeRgn (mBarRgn);
  1636. }
  1637.  
  1638. And here's how they are called:
  1639.  
  1640. main (void)
  1641. {
  1642.     Do_Init_Managers ();    // Gee!  What's this do?
  1643.     Set_Data_Array ();    // Some initializations.
  1644.     Init_Variables ();    // More init.
  1645.     HideMenuBar ();        // Take a little off the top.
  1646.     Set_Up_Window ();    // Get ready for showtime.
  1647.     HideCursor ();        // Get rid of "the fly."
  1648.     Main_Event_Loop ();    // ACTION!
  1649.     ShowCursor ();        // Action's over, bring back some control.
  1650.     ShowMenuBar ();        // Bring this back.
  1651.     DisposeWindow (&window);// Dump this, an the RAM in rode in on.
  1652.     ExitToShell ();        // Get back home, Loretta!
  1653. }                // We're in the Finder.
  1654.  
  1655. -Ken-
  1656.  
  1657. ---------------------------
  1658.  
  1659. >From rod@faceng.anu.edu.au
  1660. Subject: C code for scrollable application help
  1661. Date: 3 Mar 1994 22:19:21 GMT
  1662. Organization: Department of Engineering, ANU, Australia
  1663.  
  1664. I recall from somewhere that there exists some code example
  1665. for providing a scrollable text window designed for providing
  1666. help information (possibly with an indexing facility).  Can someone
  1667. direct me to the source (if it exists)?
  1668.  
  1669. My Freeware application has full Balloon help but I'd like to complement
  1670. it with information akin to readme files.
  1671.  
  1672. Thanks in advance.
  1673.  
  1674. Rod
  1675.  
  1676.  
  1677.  
  1678. +++++++++++++++++++++++++++
  1679.  
  1680. >From kidwell@wam.umd.edu (Christopher Bruce Kidwell)
  1681. Date: 4 Mar 1994 14:30:05 GMT
  1682. Organization: University of Maryland, College Park
  1683.  
  1684. In article <2l5npaINN75o@dubhe.anu.edu.au>,  <rod@faceng.anu.edu.au> wrote:
  1685. >I recall from somewhere that there exists some code example
  1686. >for providing a scrollable text window designed for providing
  1687. >help information (possibly with an indexing facility).  Can someone
  1688. >direct me to the source (if it exists)?
  1689.  
  1690. on mac.archive.umich.edu: /development/source/help.cpt.hqx
  1691. It uses a styled TEXT resource to display scrollable text with a popup
  1692. menu to jump to different sections. That version shows the help in a
  1693. modal dialog box -- I don't know if there's a moveable modal version
  1694. out there anywhere.
  1695.  
  1696. Chris Kidwell
  1697. kidwell@wam.umd.edu
  1698.  
  1699.  
  1700.  
  1701. +++++++++++++++++++++++++++
  1702.  
  1703. >From chuck@gte.com (Chuck Hoffman)
  1704. Date: Fri, 4 Mar 1994 15:19:53 GMT
  1705. Organization: GTE Laboratories
  1706.  
  1707. In article <2l5npaINN75o@dubhe.anu.edu.au>, rod@faceng.anu.edu.au wrote:
  1708.  
  1709. > I recall from somewhere that there exists some code example
  1710. > for providing a scrollable text window designed for providing
  1711. > help information (possibly with an indexing facility).  Can someone
  1712. > direct me to the source (if it exists)?
  1713. > My Freeware application has full Balloon help but I'd like to complement
  1714. > it with information akin to readme files.
  1715. > Thanks in advance.
  1716. > Rod
  1717.  
  1718. You might find the Help routines useful in the sample application Chassis
  1719. 6.0.  The text is simple, non-styled text.
  1720.  
  1721. The text and the selection list are both scrollable.
  1722.  
  1723. The window is not a dialog, and can remain open while other windows are in
  1724. use.
  1725.  
  1726. The text is kept in the resource fork.
  1727.  
  1728. The Help menu item is on the Apple menu.  In release 6.1 it will be moved
  1729. to the Help (baloon) menu.  (6.1 will also be AppleEvent aware.)
  1730.  
  1731. Chassis 6.0 is freeware.  It is available at mac.archive.umich.edu and its
  1732. mirror sites, also at CompuServe and America OnLine.  Chassis 6.0 is also
  1733. available directly from us at ftp.gte.com, file
  1734. /pub/chuck/Chassis_6.0.sea.hqx
  1735.  
  1736. DO NOT USE THE VERSION AT SUMEX-AIM.STANFORD.EDU.  Inexplicably, they never
  1737. posted the new version.  The one they have, 4.3 or so, is not 32-bit clean
  1738. and won't compile with THINK C 6.0.  (Don't ask me... I sent the new
  1739. version to them twice.)
  1740.  
  1741. -- 
  1742. Chuck Hoffman
  1743. GTE Laboratories, Waltham, MA, USA
  1744. 617-466-2131
  1745. - ------------------------------------------------
  1746. I'm not sure why we're here, but I am sure that
  1747. while we're here we're supposed to help each other.
  1748. - ------------------------------------------------
  1749.  
  1750. +++++++++++++++++++++++++++
  1751.  
  1752. >From Robert Hess <robert_hess@macweek.ziff.com>
  1753. Date: Wed, 9 Mar 1994 02:40:56 GMT
  1754. Organization: MacWEEK
  1755.  
  1756. In article <2l7gld$kgq@cville-srv.wam.umd.edu> Christopher Bruce Kidwell,
  1757. kidwell@wam.umd.edu writes:
  1758. >on mac.archive.umich.edu: /development/source/help.cpt.hqx
  1759. >It uses a styled TEXT resource to display scrollable text with a popup
  1760. >menu to jump to different sections. That version shows the help in a
  1761. >modal dialog box -- I don't know if there's a moveable modal version
  1762. >out there anywhere.
  1763.  
  1764. You!re thinking of James Walker!s !show_help!, version 2.0 of which
  1765. offers a
  1766. movable modal.
  1767.  
  1768. =======================================================================
  1769. ====
  1770. Robert Hess, WEEKgeek                        AppleLink: WNDZSX
  1771. MacWEEK                                      CompuServe: 72511,333
  1772. 301 Howard                                   America Online: MacWEEK
  1773. San Francisco, Calif. 94105                  MCI: RHESS
  1774. (415) 243-3576 days                          Internet:
  1775. (415) 243-3651 fax                             
  1776. robert_hess@macweek.ziff.com
  1777. (415) 647-5549 nights
  1778.               I speak for myself.  And sometimes not even that.
  1779. =======================================================================
  1780. ====
  1781.  
  1782. ---------------------------
  1783.  
  1784. >From mfi@i-link.com (MicroFrontier Inc.)
  1785. Subject: Can C be as fast as Assembler? (next...on the McLaughlin Group)
  1786. Date: 28 Feb 1994 09:37:13 -0600
  1787. Organization: I-Link, Ltd., Des Moines, IA, USA - 515/255-2754
  1788.  
  1789.  
  1790.  
  1791. OK, I've heard both sides of the story here...some developers say that C
  1792. can be as fast as assembler (or at least very, very close), provided it is
  1793. written well enough. Other say that C code doesn't get anywhere near the
  1794. speed of assembler, no matter how it's written.
  1795.  
  1796. Now, I would imagine that C can get closer to assembly depending on the
  1797. task that is being done....what tasks would those be?
  1798.  
  1799. What's the best way to optimize C?
  1800.  
  1801. And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  1802. produces the fastest C code (with all optimization turned on)? Which do
  1803. you think produces the best quality code (if being the fastest doesn't
  1804. make it the best quality by default)?
  1805.  
  1806. Please post responses to the net...I'm sure this is something we can all
  1807. benefit from. Also, please try to keep it civil. :-)
  1808.  
  1809.  
  1810.  
  1811. -kevin
  1812.  
  1813. +++++++++++++++++++++++++++
  1814.  
  1815. >From chyang@quip.eecs.umich.edu (Chung-Hsiung Yang)
  1816. Date: 28 Feb 1994 16:11:50 GMT
  1817. Organization: University of Michigan EECS Dept., Ann Arbor, MI
  1818.  
  1819. In article <2kt339$589@ilink1.i-link.com>, mfi@i-link.com (MicroFrontier Inc.) writes:
  1820. |> 
  1821. |> 
  1822. |> OK, I've heard both sides of the story here...some developers say that C
  1823. |> can be as fast as assembler (or at least very, very close), provided it is
  1824. |> written well enough. Other say that C code doesn't get anywhere near the
  1825. |> speed of assembler, no matter how it's written.
  1826. |> 
  1827. |> Now, I would imagine that C can get closer to assembly depending on the
  1828. |> task that is being done....what tasks would those be?
  1829. |> 
  1830. |> What's the best way to optimize C?
  1831.  
  1832.     I don't think this is really a good way to look at both sides of
  1833. the world.  I tend to agree that assembler will be faster than C generated
  1834. code because programming in assembler requires the programmer to optimize
  1835. (some what) the code as you go alone because you are dealing
  1836. with much lower semantics than C.  On the other hand, the level of optimization
  1837. one could do with C is really more dependent on the compiler itself.
  1838.  
  1839.     But look what you are doing here.  What do you want to do with 
  1840. assembler vs. C?  If you restrict yourself to the assembler world, then
  1841. you are limited to pretty small programs with pretty limited software
  1842. architecture.  Maybe you could write routines
  1843. for a small, but very fast computation that does for example some process
  1844. in digital signal processing.  Because of the overhead in C, you would 
  1845. probably not be able to achieve the speed that you could obtain with C.
  1846.  
  1847.     But imagine yourself writing a 100,000 line code in C.  Quite a
  1848. big project.  Imagin writing the same code in assembly, you will probably
  1849. have to write close to a million line or more.  When you get to a million
  1850. lines of code in assember, how do you optimize it?  It is a scary thought,
  1851. I wouldn't do it.  In this case I would rather depend on a well designed
  1852. C compiler to do the job.  In this case, I think for very big programs C
  1853. would very likely produce faster codes because there is no way for human
  1854. beings to program codes that big in assembly.  Also when you get to 
  1855. that programs that size, there are many tricks that one could play to
  1856. optimize the code than assembly because, the notion of a high level 
  1857. software architecture such as object oriented design just could not be
  1858. easily achieved by assembly.  (You could do it, but it will be very hard).
  1859.  
  1860.  
  1861. - Chung Yang
  1862.  
  1863. |> And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  1864. |> produces the fastest C code (with all optimization turned on)? Which do
  1865. |> you think produces the best quality code (if being the fastest doesn't
  1866. |> make it the best quality by default)?
  1867. |> 
  1868. |> Please post responses to the net...I'm sure this is something we can all
  1869. |> benefit from. Also, please try to keep it civil. :-)
  1870. |> 
  1871. |> 
  1872. |> 
  1873. |> -kevin
  1874.  
  1875. +++++++++++++++++++++++++++
  1876.  
  1877. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  1878. Date: Mon, 28 Feb 1994 16:30:42 GMT
  1879. Organization: The Great Beyond
  1880.  
  1881. In article <2kt546$23o@zip.eecs.umich.edu> chyang@quip.eecs.umich.edu (Chung-Hsiung Yang) writes:
  1882. >In article <2kt339$589@ilink1.i-link.com>, mfi@i-link.com (MicroFrontier Inc.) writes:
  1883. >|> 
  1884. >|> 
  1885. >|> OK, I've heard both sides of the story here...some developers say that C
  1886. >|> can be as fast as assembler (or at least very, very close), provided it is
  1887. >|> written well enough. Other say that C code doesn't get anywhere near the
  1888. >|> speed of assembler, no matter how it's written.
  1889. >|> 
  1890. >|> Now, I would imagine that C can get closer to assembly depending on the
  1891. >|> task that is being done....what tasks would those be?
  1892. >|> 
  1893. >|> What's the best way to optimize C?
  1894.  
  1895.    Well, first, I'd say in many cases a lot of blame is put on the compiler
  1896. producing "unoptimized" code when the user could in fact be optimizing
  1897. their program.
  1898.  
  1899.    Meaning, often great speed increases can be seen by changing the way
  1900. your program does certain things.  If you do a sort, are you using a
  1901. bubble sort or a quicker sort?  Things like that.  Once you've done a
  1902. good job in that arena, then it comes time when you can benefit from
  1903. better code production.
  1904.  
  1905.    Most compilers (such as Think C) have a "dissassemble" option that
  1906. allow you to look at the assembly the compiler is producing.  This is
  1907. helpful if you know assembly; if you don't, it may not be too useful.
  1908. But if you can read assembly, you can see exactly how the compiler is
  1909. interpreting your code and try making modifications to your code so
  1910. that the resultant assembly is better.  Compilers are smart, but they're
  1911. not geniouses -- often switching two lines around will signal the compiler
  1912. to use some trick to make something much quicker.
  1913.  
  1914.    I wouldn't recommend writing in Assembly unless you absolutely need
  1915. to; that will be weighted yourself down with concrete bricks when you
  1916. want to take your program into the future.  The PowerPC is an excellent
  1917. case in point.  The programmers who are porting their applications in
  1918. two days are the ones who don't have any of their code in assembly.
  1919.  
  1920.    But a knowledge of 680x0 or PPC assembly is useful; again, you can
  1921. tweak your C code around so it results in better assembly production
  1922. with your compiler, without jeopardizing future compatibility.
  1923.  
  1924. >|> And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  1925. >|> produces the fastest C code (with all optimization turned on)? Which do
  1926. >|> you think produces the best quality code (if being the fastest doesn't
  1927. >|> make it the best quality by default)?
  1928.  
  1929.    I think this is impossible to say.  Each compiler is different, and
  1930. each one might produce better code in some places and not others.
  1931.  
  1932.    Unless one has obvious code generator flaws, they're all probably
  1933. pretty good.  Code optimization (on the compiler's part) is tricky stuff,
  1934. from what I understand.  Remember: the compiler basically just does the
  1935. "brute force" work of taking your C and transforming it into working,
  1936. equivalent assembly.  This doesn't require much "smarts" on the compiler's
  1937. part.
  1938.  
  1939.    To look at the C code, and to find tricks for performing the same
  1940. function with less instructions, takes great problem-solving skills and
  1941. insight which humans often have, but which is difficult to duplicate
  1942. in computers.
  1943.  
  1944.    Each compiler author will no doubt provide that "intelligence" in
  1945. their optimizers in different ways.  Each compiler probably knows
  1946. different tricks.  One routine of yours might result in lots of
  1947. tricks with compiler X, but none in compiler Y.  But with your next
  1948. routine the reverse might be true.
  1949.  
  1950.    I don't know how to define "best quality" in terms other than speed.
  1951. Presumably, a compiler is going to produce _100% working code_.  There's
  1952. no room for errors (on the compiler's part, anyway).  So you'd expect
  1953. any code a compiler produces to work.  The next criterion is "how quickly
  1954. does it work?"  This is where the optimization comes in.  I can't
  1955. really think of better ways to measure quality of code generation,
  1956. if you make the assumption that any code coming from a compiler isn't
  1957. going to have any bugs introduced by the compiler.  (That may not always
  1958. be a valid assumption.)
  1959.  
  1960. Just my thoughts..
  1961.  
  1962. Scott
  1963.  
  1964. - -
  1965. M. Scott Smith         (mssmith@afterlife.ncsc.mil)
  1966.  
  1967.   Macintosh developer.. Student.. Ski bum.  Eater of Kellog's Frosted Flakes.
  1968.  
  1969.      "Last stop for fuel on the information highway"
  1970.  
  1971.  
  1972. +++++++++++++++++++++++++++
  1973.  
  1974. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  1975. Date: 28 Feb 94 18:05:12
  1976. Organization: Integrated Systems Laboratory, ETH, Zurich
  1977.  
  1978. In article <2kt339$589@ilink1.i-link.com>, mfi@i-link.com (MicroFrontier Inc.) writes:
  1979.  
  1980. > OK, I've heard both sides of the story here...
  1981.  
  1982. Really? I haven't seen a hardcore assembler advocate here in a long time.
  1983.  
  1984. > some developers say that C
  1985. > can be as fast as assembler (or at least very, very close), provided it is
  1986. > written well enough. Other say that C code doesn't get anywhere near the
  1987. > speed of assembler, no matter how it's written.
  1988.  
  1989. Assembler is much slower than C in several respects:
  1990.  
  1991.  - Almost all code (with a few exceptions) takes longer to write, debug, and
  1992.    maintain in Assembler. Note that for the same reasons, C++ is also faster
  1993.    than C, Eiffel is faster than C++, and Perl for some tasks is much faster
  1994.    than all of them.
  1995.  - You will find it easier to identify and rewrite speed critical parts in a C
  1996.    program than in an assembler program.
  1997.  - A C application compiled with an "Optimizing for PowerPC" compiler will
  1998.    run circles around your 680X0 assembler code.
  1999.    
  2000. > Now, I would imagine that C can get closer to assembly depending on the
  2001. > task that is being done....what tasks would those be?
  2002.  
  2003. Depends also a lot on the compiler and the target processor. The 680X0 is
  2004. a reasonable code generation target, and so is the PowerPC. In some ways, the
  2005. PowerPC will be easier, but new factors like instruction scheduling come into
  2006. play. I think assembly language progarmmers will have a harder time beating
  2007. compilers on PowerPCs, since instruction scheduling is rather hard to do in
  2008. one's head (Except if you are the infamous Mel, who programmed  rotating disk
  2009. memory machines).
  2010.  
  2011. > What's the best way to optimize C?
  2012.  
  2013. Use a good compiler. Profile. Rewrite critical sections. repeat.
  2014.  
  2015. > And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  2016. > produces the fastest C code (with all optimization turned on)?
  2017.                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2018.  
  2019. One problem I ahve with Mac C compilers is that at least for some of them,
  2020. turning on optimizaion is too dangerous to do for an entire program.
  2021.  
  2022. > Which do
  2023. > you think produces the best quality code (if being the fastest doesn't
  2024. > make it the best quality by default)?
  2025.  
  2026. I'd take a reliable compiler over a fast compiler or one producing fast code
  2027. anytime.
  2028.  
  2029. > Also, please try to keep it civil. :-)
  2030.  
  2031. With a topic like this??
  2032.  
  2033. Matthias
  2034.  
  2035. - ---
  2036. Matthias Neeracher                                      neeri@iis.ethz.ch
  2037.   "And I won this ribbon in a Degradation Contest at the Teheran
  2038.    meeting of Junkies Anonymous" -- William Burroughs, _The Naked Lunch_
  2039.  
  2040. +++++++++++++++++++++++++++
  2041.  
  2042. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  2043. Date: 1 Mar 1994 12:03:20 +0800
  2044. Organization: NCRPDA, Curtin University
  2045.  
  2046. mfi@i-link.com (MicroFrontier Inc.) writes:
  2047.  
  2048. >OK, I've heard both sides of the story here...some developers say that C
  2049. >can be as fast as assembler (or at least very, very close), provided it is
  2050. >written well enough. Other say that C code doesn't get anywhere near the
  2051. >speed of assembler, no matter how it's written.
  2052.  
  2053. C or Pascal produce about teh same quality code.  It's generally about
  2054. half the speed of reasonably tight assembly code (although an important
  2055. thing to remember before converting your code from C/Pascal to asm is
  2056. that while you might get a double speed imporvement, redesigning the 
  2057. *algorithm* used may get you orders of magnitude of imporvement, and also
  2058. asm can't be recompiled on the PPC to get you ~4 times speed improvement 
  2059. going native instead of interpreted.
  2060.  
  2061. >Now, I would imagine that C can get closer to assembly depending on the
  2062. >task that is being done....what tasks would those be?
  2063.  
  2064. Small, simple, processor intensive things can be done more more quickly
  2065. in asm (eg BlockMove, Character translation (ISO<->Mac, <crlf><-><cr>,
  2066. BinHex/UU translation, etc)).  Large things are better written in a high
  2067. level language for the reasons stated above (easier to improve the
  2068. algorithm, easier to compile on faster machines) (not to mention all the
  2069. other obvious advantages (portability (kinda ;-), maintenance (kinda ;-),
  2070. etc).
  2071.  
  2072. >What's the best way to optimize C?
  2073.  
  2074. Don't use any pointers.  Pointers screw up optimizing compilers.
  2075.  
  2076. >And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  2077. >produces the fastest C code (with all optimization turned on)? Which do
  2078. >you think produces the best quality code (if being the fastest doesn't
  2079. >make it the best quality by default)?
  2080.  
  2081. No idea, they are probably all withing 10% (as is Pascal, normally on
  2082. the faster side).
  2083.    Peter.
  2084. -- 
  2085. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  2086.  
  2087. +++++++++++++++++++++++++++
  2088.  
  2089. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  2090. Date: Mon, 28 Feb 1994 22:25:15 -0600
  2091. Organization: University of Illinois at Urbana-Champaign
  2092.  
  2093. In article <2kueq8$865@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au
  2094. (Peter N Lewis) wrote:
  2095.  
  2096. >>What's the best way to optimize C?
  2097. >
  2098. >Don't use any pointers.  Pointers screw up optimizing compilers.
  2099.  
  2100. What?!?! Sometimes using pointers is the only way to get a really stupid
  2101. compiler to do register allocation and register loading properly.
  2102.  
  2103. pr
  2104. -- 
  2105. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  2106. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  2107. System manager - Cognitive Science Group, Beckman Institute, UIUC
  2108. Internet: resnick@cogsci.uiuc.edu
  2109.  
  2110. +++++++++++++++++++++++++++
  2111.  
  2112. >From ari@world.std.com (Ari I Halberstadt)
  2113. Date: Tue, 1 Mar 1994 07:17:57 GMT
  2114. Organization: The World Public Access UNIX, Brookline, MA
  2115.  
  2116. In article <NEERI.94Feb28180512@yggdrasil.ethz.ch>,
  2117. Matthias Neeracher <neeri@iis.ee.ethz.ch> wrote:
  2118. > - Almost all code (with a few exceptions) takes longer to write, debug, and
  2119. >   maintain in Assembler. Note that for the same reasons, C++ is also faster
  2120. >   than C, Eiffel is faster than C++, and Perl for some tasks is much faster
  2121. >   than all of them.
  2122.  
  2123. If only Eiffel were more widely available (like, for the mac), and a
  2124. bit cheaper for us poorer programmers. Five years ago I fell in love
  2125. with Eiffel, but it's still not on the mac (except for A/UX), which
  2126. makes it a bit slower than C or C++.
  2127. -- 
  2128. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  2129. "These beetles were long considered to be very rare because very few
  2130. entomologists look for beetles in the mountains, in winter, at night,
  2131. during snow storms." -- Purves W. K., et al, "Life: The Science of
  2132.  
  2133. +++++++++++++++++++++++++++
  2134.  
  2135. >From jim@brunner.wf.com (Jim Brunner)
  2136. Date: 28 Feb 94 14:57:34 GMT
  2137. Organization: (none)
  2138.  
  2139.  
  2140. In article <2kt339$589@ilink1.i-link.com>, you write:
  2141. > OK, I've heard both sides of the story here...some developers say that C
  2142. > can be as fast as assembler (or at least very, very close), provided it 
  2143. is
  2144. > written well enough. Other say that C code doesn't get anywhere near the
  2145. > speed of assembler, no matter how it's written.
  2146. > Now, I would imagine that C can get closer to assembly depending on the
  2147. > task that is being done....what tasks would those be?
  2148. > What's the best way to optimize C?
  2149.  
  2150. The best way to optimize ANY program in ANY language is to take a hard look 
  2151. at the algorithms in use.  For almost any program with noticable 
  2152. performance problems, 90% better speed is all in the algorithm.  It's only 
  2153. when you get down to those last few tweeks for fractions of a percent that 
  2154. assembler *might* make any difference.  (Of course, I'm talking in the 
  2155. general case - like the original poster.  There are, of course, 
  2156. exceptions.)
  2157.  
  2158. Try profiling your code.  Run your program with a profiler (like the one 
  2159. included with Think C) and find out where it's spending it's time.  Most 
  2160. likely, 90% of the time will be in 10% of the code.  Look at that 10% and 
  2161. ignore the rest.  Look at the algorithms first - searching a linked list 
  2162. instead of a binary tree?
  2163.  
  2164. Make a decision:  How many people does this affect, how critical is it?  If 
  2165. the program in question isn't very critical, it might be more cost 
  2166. effective to ignore the problem.  If not too many people use the program, 
  2167. it may be more cost effective to buy a faster machine.  Assembly language 
  2168. is expensive.  It's expensive in programmer time and maintenance cost.
  2169.  
  2170. Go further only for those few lines of highly critical code - realize that 
  2171. these changes are not necessarily beneficial across platforms.  Start by 
  2172. disassembling the code generated by the C compiler.  Take a look at how 
  2173. slight coding changes affect the generated code.
  2174.  
  2175. Only on highly critical sections of code (counting clock cycles here), go 
  2176. to assembler and hand code the critical section (if the compiler didn't do 
  2177. it well enough to begin with.
  2178.  
  2179. These days, assembler code is almost extinct.  I've seen it used recently 
  2180. on a small subroutine that was part of the firmware running on a DSP chip - 
  2181. there was a timing limitation in # of clock cycles.
  2182. - -
  2183. Jim Brunner (jim@brunner.wf.com)
  2184.  
  2185. +++++++++++++++++++++++++++
  2186.  
  2187. >From gregor@nrlfs1.nrl.navy.mil (joe gregor)
  2188. Date: Tue, 1 Mar 1994 14:29:37 GMT
  2189. Organization: NRL
  2190.  
  2191. In Article <2kueq8$865@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au
  2192. (Peter N Lewis) wrote:
  2193.  
  2194. >C or Pascal produce about teh same quality code.  It's generally about
  2195. >half the speed of reasonably tight assembly code...
  2196.  
  2197. >>And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  2198. >>produces the fastest C code (with all optimization turned on)? Which do
  2199. >>you think produces the best quality code (if being the fastest doesn't
  2200. >>make it the best quality by default)?
  2201. >
  2202. >No idea, they are probably all withing 10% (as is Pascal, normally on
  2203. >the faster side).
  2204.  
  2205.     I had always heard/read that C was the fastest language next to asm.
  2206. I *never* heard/read that Pascal was even close, let alone faster. Please
  2207. identify your references so I may (re)educate myself.
  2208.  
  2209.     -- Joe
  2210. ________________________________________________________________________________
  2211.  
  2212.  Joseph Gregor                  |   
  2213.     gregor@ccf.nrl.navy.mil     |      THIS SPACE INTENTIONALLY LEFT BLANK.
  2214.        tmh@eng.umd.edu          |
  2215. ________________________________|_______________________________________________
  2216.  
  2217. +++++++++++++++++++++++++++
  2218.  
  2219. >From jwbaxter@olympus.net (John W. Baxter)
  2220. Date: Tue, 01 Mar 1994 08:35:48 -0800
  2221. Organization: Internet for the Olympic Peninsula
  2222.  
  2223. In article <9402281957344983@brunner.wf.com>, jim@brunner.wf.com (Jim
  2224. Brunner) wrote:
  2225.  
  2226. > Go further only for those few lines of highly critical code - realize that 
  2227. > these changes are not necessarily beneficial across platforms.
  2228.  
  2229. Keeping in mind that "across platforms" above in some cases includes
  2230. differences among the 68000, 68020, 68030, and 68040.  You may have to
  2231. decide which of those you want to target (probably 68040 these days, say I
  2232. who still runs a 68030), at the cost of hurting the others.
  2233.  
  2234. -- 
  2235. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  2236.    jwbaxter@pt.olympus.net
  2237.  
  2238. +++++++++++++++++++++++++++
  2239.  
  2240. >From mmorgan@gpu.srv.ualberta.ca (Martin Morgan)
  2241. Date: 1 Mar 1994 17:31:22 GMT
  2242. Organization: University of Alberta
  2243.  
  2244. Peter N Lewis (peter@ncrpda.curtin.edu.au) wrote:
  2245. : mfi@i-link.com (MicroFrontier Inc.) writes:
  2246. : >What's the best way to optimize C?
  2247. : Don't use any pointers.  Pointers screw up optimizing compilers.
  2248.  
  2249. Is this true? Is it true in a more restricted sense, don't use pointers in
  2250. speed-critical sections of code?
  2251.  
  2252. Martin Morgan
  2253. University of Alberta
  2254.  
  2255.  
  2256. +++++++++++++++++++++++++++
  2257.  
  2258. >From nagle@netcom.com (John Nagle)
  2259. Date: Tue, 1 Mar 1994 18:40:47 GMT
  2260. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  2261.  
  2262. mfi@i-link.com (MicroFrontier Inc.) writes:
  2263. >OK, I've heard both sides of the story here...some developers say that C
  2264. >can be as fast as assembler (or at least very, very close), provided it is
  2265. >written well enough. Other say that C code doesn't get anywhere near the
  2266. >speed of assembler, no matter how it's written.
  2267.  
  2268.       Depends on the compiler.  Both MPW C and Symantec C++ are worse than,
  2269. say, mainframe FORTRAN compilers of the late 1960s.  Good compilers
  2270. for the 680x0 machines exist, but not on the Mac.  MetaWare High-C
  2271. is available for the 68000, but they market it to embedded systems
  2272. makers, not Macs.  The Sun compiler for the older 68000 Suns were
  2273. reasonably good as well, and one large CAD package for the Mac used
  2274. to be cross-compiled on a Sun to take advantage of this.
  2275.  
  2276.       I like to try compiling
  2277.  
  2278.         int i; char tab1[100]; tab2[100];
  2279.         for (i=0; i<100; i++) tab1[i] = tab2[i];
  2280.  
  2281. and see what the inner loop looks like.  Ideally, the inner loop
  2282. should have two instructions, but I've seen as many as 12.
  2283.  
  2284. Incidentally, using subscripts vs pointer incrementation does not make
  2285. much difference with most modern compilers.  Even SC++ gets this one
  2286. right.
  2287.  
  2288.       The big SC++ problem is really dumb register usage.  One sees
  2289. lots of unnecessary register-to-register moves in SC++ output.  The
  2290. compiler never seems to take full advantage of all the registers
  2291. available (it's a port of a compiler for Intel CPUs, which have 
  2292. fewer registers).  In the compiler-design world, using all the registers
  2293. effectively is generally considered a win even when not "optimizing", 
  2294. because it takes less time to figure out which register to use than
  2295. to generate the register-to-register moves and stack manipulation
  2296. required when doing it wrong.  The global optimizer does a good job, though, 
  2297. except when it makes mistakes.  
  2298.  
  2299.       MPW C has a better code generator but a weaker global optimizer.
  2300.  
  2301.       I tried this simple test case on a pre-release MetroWerks
  2302. compiler, and it generated OK, but not spectacular code.
  2303.  
  2304.       Still, if there was a compiler for the Mac that generated state of the
  2305. art optimized code, programs would be perhaps twice as fast in some cases,
  2306. and somewhat smaller.  
  2307.  
  2308.                     John Nagle
  2309.  
  2310.  
  2311. +++++++++++++++++++++++++++
  2312.  
  2313. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  2314. Date: 1 Mar 1994 23:13:52 GMT
  2315. Organization: Royal Institute of Technology, Stockholm, Sweden
  2316.  
  2317. >>>What's the best way to optimize C?
  2318.  
  2319. >>Don't use any pointers.  Pointers screw up optimizing compilers.
  2320.  
  2321. >What?!?! Sometimes using pointers is the only way to get a really stupid
  2322. >compiler to do register allocation and register loading properly.
  2323.  
  2324. Yes, but at the same time, pointers (and especially when assigned to
  2325. addresses of local variables) can limit more sophisticated compilers,
  2326. since they can't do a full analysis of where your pointer might point
  2327. and what short-cuts it can take.
  2328.  
  2329. -- 
  2330.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  2331.  
  2332.    Cookie Jar: Vanilla Yoghurt with Crushed Oreos.
  2333.  
  2334. +++++++++++++++++++++++++++
  2335.  
  2336. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  2337. Date: Tue, 01 Mar 1994 17:32:34 -0600
  2338. Organization: University of Illinois at Urbana-Champaign
  2339.  
  2340. In article <2l0i7g$o51@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte)
  2341. wrote:
  2342.  
  2343. >>What?!?! Sometimes using pointers is the only way to get a really stupid
  2344. >>compiler to do register allocation and register loading properly.
  2345. >
  2346. >Yes, but at the same time, pointers (and especially when assigned to
  2347. >addresses of local variables) can limit more sophisticated compilers,
  2348. >since they can't do a full analysis of where your pointer might point
  2349. >and what short-cuts it can take.
  2350.  
  2351. Compilers are generally stupid. If you disassemble code resources you'll
  2352. see that MPW C is stupider than THINK C, but THINK C is pretty stupid too.
  2353. I am waiting for someone to release a compiler that does peep-hole
  2354. optimization. Does anyone by any chance know if MetroWorks does so?
  2355.  
  2356. Here's a rash claim (flames against my ignorance welcome): Stupid
  2357. compilers are why RISC processors do better than CISC processors. If
  2358. compilers were smart enough to take advantage of all of the interesting
  2359. addressing modes and instructions on CISC architectures, CISCs would
  2360. overall be faster at running programs than RISCs. (*Duck*)
  2361.  
  2362. pr
  2363. -- 
  2364. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  2365. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  2366. System manager - Cognitive Science Group, Beckman Institute, UIUC
  2367. Internet: resnick@cogsci.uiuc.edu
  2368.  
  2369. +++++++++++++++++++++++++++
  2370.  
  2371. >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik)
  2372. Date: 02 Mar 1994 01:25:16 GMT
  2373. Organization: Case Western Reserve University, Cleveland, Ohio (USA)
  2374.  
  2375. In article <2kvu5a$b06@quartz.ucs.ualberta.ca> mmorgan@gpu.srv.ualberta.ca (Martin Morgan) writes:
  2376.  
  2377.    Peter N Lewis (peter@ncrpda.curtin.edu.au) wrote:
  2378.    : mfi@i-link.com (MicroFrontier Inc.) writes:
  2379.    : >What's the best way to optimize C?
  2380.    : Don't use any pointers.  Pointers screw up optimizing compilers.
  2381.  
  2382.    Is this true? Is it true in a more restricted sense, don't use pointers in
  2383.    speed-critical sections of code?
  2384.  
  2385. using pointers does NOT directly result in slower code.  there are many
  2386. cases where pointers can be used to generate significantly optimized
  2387. code.
  2388.  
  2389. however, if you use pointers you should be aware of the fact that the
  2390. code optimizer now can make fewer assumptions about your code, and 
  2391. thus it may not be able to apply certain optimizations.
  2392.  
  2393. get a good book on compiler writing (eg: Aho, Sethi & Ullman) and
  2394. read the sections on optimizing.  understanding how optimizers work
  2395. will greatly aid your programming: you'll have a better understanding
  2396. of what the compiler can annd cannot do.
  2397.  
  2398.  
  2399. -gary j kacmarcik
  2400. platypus@curie.ces.cwru.edu
  2401.  
  2402.  
  2403. +++++++++++++++++++++++++++
  2404.  
  2405. >From siegel@netcom.com (Rich Siegel)
  2406. Date: Wed, 2 Mar 1994 05:41:38 GMT
  2407. Organization: Bare Bones Software
  2408.  
  2409. In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2410. >
  2411. >Compilers are generally stupid. If you disassemble code resources you'll
  2412. >see that MPW C is stupider than THINK C, but THINK C is pretty stupid too.
  2413. >I am waiting for someone to release a compiler that does peep-hole
  2414. >optimization. Does anyone by any chance know if MetroWorks does so?
  2415.  
  2416. Metrowerks does. So does THINK C. So does MPW C.
  2417.  
  2418. >Here's a rash claim (flames against my ignorance welcome): Stupid
  2419. >compilers are why RISC processors do better than CISC processors. If
  2420. >compilers were smart enough to take advantage of all of the interesting
  2421. >addressing modes and instructions on CISC architectures, CISCs would
  2422. >overall be faster at running programs than RISCs. (*Duck*)
  2423.  
  2424. I have a reality adjustment for you. On the 68020, many of the fancy
  2425. addressing modes are either a wash or are actually slower than an
  2426. equivalent sequence of instructions using 68000-only addressing modes.
  2427.  
  2428. R.
  2429.  
  2430. -- 
  2431. Rich Siegel % siegel@netcom.com    % Principal, Bare Bones Software
  2432. --> For information about BBEdit, finger bbedit@world.std.com <--
  2433.  
  2434. "He then proceeded to give a history of the universe, in real time."
  2435.  
  2436. +++++++++++++++++++++++++++
  2437.  
  2438. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  2439. Date: 2 Mar 1994 13:20:52 +0800
  2440. Organization: NCRPDA, Curtin University
  2441.  
  2442. >From: chewy@shell.portal.com (Paul Snively)
  2443. >...
  2444. >q = *p++;
  2445. >...
  2446. >q = *p++;
  2447. >...
  2448. >
  2449. >Note that the above code features common subexpressions (in fact, for
  2450.  
  2451. No, they are not cse's.  To be eleigable for cse elemination, the 
  2452. expression must not have any side effects.  I'd quote chapter and verse
  2453. out of the Dragon book, but I don't have it handy.
  2454.  
  2455. >The moral of the story is twofold: a) try to write clean, readable code
  2456. >that doesn't rely on nasty compound functions, especially with
  2457. >side-effects; and b) know thy optimizer.  If you need help, disassemble
  2458. >the code and see what your optimizer is doing behind your back.
  2459.  
  2460. No, a) is certainly true, but b) should not be.  The optimizer should
  2461. never change the way your program behaves - if it does, either the optimizer
  2462. is broken (like the THINK C optimizer), or your program is broken.
  2463.  
  2464. >From: gregor@nrlfs1.nrl.navy.mil (joe gregor)
  2465.  
  2466. >>No idea, they are probably all withing 10% (as is Pascal, normally on
  2467. >>the faster side).
  2468.  
  2469. >    I had always heard/read that C was the fastest language next to asm.
  2470. >I *never* heard/read that Pascal was even close, let alone faster. Please
  2471. >identify your references so I may (re)educate myself.
  2472.  
  2473. You've probably heard thousands of people tell you PCs are better than Macs.
  2474.  
  2475. Try it and see for yourself.  Pascal compilers will generally produce faster
  2476. code than C compilers with equivalent source.  Obviously, compilers vary
  2477. a great deal, but the above is generally true.  I wouldn't worry though,
  2478. I expect the next generation of compilers will make C faster than Pascal,
  2479. since Pascal compilers will get a lot less work done on them.  Of course,
  2480. then everyone will be using C++ and efficiency will be thrown right out
  2481. the window, but such is life ;-)
  2482.  
  2483. >From: mmorgan@gpu.srv.ualberta.ca (Martin Morgan)
  2484.  
  2485. >: Don't use any pointers.  Pointers screw up optimizing compilers.
  2486. >
  2487. >Is this true? Is it true in a more restricted sense, don't use pointers in
  2488. >speed-critical sections of code?
  2489.  
  2490. What I said is true, in that pointers screw up most really clever high
  2491. level optimizations because the compiler has an impossible task
  2492. of figuring out what you're doing.  For example, if you do this:
  2493.  
  2494. x = 5;
  2495. for i:=1 to 100 do
  2496.   arr[i] = 0;
  2497. end-for;
  2498. y = x;
  2499.  
  2500. (equivalent in C or Pascal).  It is easy for the compiler to know that
  2501. x has remained unchanged, that i is now undefined (and thus the
  2502. register can be reused), that the array has been modified, that i
  2503. is always between 1 and 100 and so no range checking needs to be done,
  2504. that y can be assigned 5 directly, etc.
  2505.  
  2506. If you instead do this:
  2507.  
  2508. x=5;
  2509. i=100;
  2510. p = @arr[1];
  2511. while (i>0) do
  2512.   *p++ = 0;
  2513.   i--;
  2514. end-while
  2515. y = x;
  2516.  
  2517. Now it is nearly impossible for the compiler to determine any of that.
  2518. It has to be really clever to figure out that p only ever points to
  2519. the array arr (a compiler would probably be allowed to assume this 
  2520. though, since it is undefined what happens if you increment a ptr outside
  2521. of the area it started in).  If the compiler can't figure that out, then
  2522. all variables must be in memory (not registers) and all are potentially
  2523. modified, so none of the optimizations above are available.
  2524.  
  2525. Of course I wouldn't worry about this either, since most compilers don't
  2526. do very much in the way of clever optimizing (and when they try, they 
  2527. usually screw it up)...
  2528.    Peter.
  2529. -- 
  2530. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  2531.  
  2532. +++++++++++++++++++++++++++
  2533.  
  2534. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  2535. Date: Wed, 02 Mar 1994 00:51:17 -0600
  2536. Organization: University of Illinois at Urbana-Champaign
  2537.  
  2538. In article <siegelCM0vtF.9F@netcom.com>, siegel@netcom.com (Rich Siegel) wrote:
  2539.  
  2540. >In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2541. >>
  2542. >>Compilers are generally stupid. If you disassemble code resources you'll
  2543. >>see that MPW C is stupider than THINK C, but THINK C is pretty stupid too.
  2544. >>I am waiting for someone to release a compiler that does peep-hole
  2545. >>optimization. Does anyone by any chance know if MetroWorks does so?
  2546. >
  2547. >Metrowerks does. So does THINK C. So does MPW C.
  2548.  
  2549. Surely you're kidding. I've seen MPW C move things back and forth between
  2550. the same two registers (or worse, to and from the stack) oodles of times
  2551. in a series of instructions with no other side effects. THINK C constantly
  2552. does 'MOVE.L (A7)+,D3' followed by a 'TST.L D3' followed by a branch on
  2553. condition code. And I've never seen either of them generate a DBcc
  2554. instruction, even when I force feed it; I have lots of code for which
  2555. THINK C generates:
  2556.  
  2557.     SUBQ.W #$1,D3
  2558.     CMPI.W #$FFFF,D3
  2559.     BNE.S  *-$000C
  2560.  
  2561. What *are* they looking for if not these kinds of things?
  2562.  
  2563. As for the RISC/CISC argument I started, I've gotten lots of really cool
  2564. mail in response, some in support and some against, but almost all of it
  2565. saying, "It's a lot more complicated than you think." I figured as much,
  2566. but I do thank everyone for their comments; I have learned a lot in the
  2567. process.
  2568.  
  2569. pr
  2570. -- 
  2571. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  2572. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  2573. System manager - Cognitive Science Group, Beckman Institute, UIUC
  2574. Internet: resnick@cogsci.uiuc.edu
  2575.  
  2576. +++++++++++++++++++++++++++
  2577.  
  2578. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  2579. Date: 2 Mar 1994 10:32:23 GMT
  2580. Organization: Royal Institute of Technology, Stockholm, Sweden
  2581.  
  2582. >I don't have my ANSI reference in front of me, but I distinctly recall
  2583. >my shock upon reading something in it that made it quite clear that the
  2584. >semantics of your program could differ between unoptimized and
  2585. >optimized versions of your code.
  2586.  
  2587. So far so good.
  2588.  
  2589. >To give just one obvious example of how this could happen, consider a
  2590. >function that uses a pointer p, and contains code like this:
  2591.  
  2592. >q = *p++;
  2593. >q = *p++;
  2594.  
  2595. >let's say I compile this code without Common Subexpression Elimination.
  2596. > The pointer gets incremented twice, which is probably what the author
  2597. >had in mind.  But if I compile with Common Subexpression Elimination
  2598. >on, the compiler is completely free to evaluate the p++ once and stick
  2599. >the result in a register.  Oops.
  2600.  
  2601. No, that's NOT legal, since this has a very well-defined semantic
  2602. meaning. What the compiler CAN do, is change its behaviour for
  2603. UNDEFINED cases, such as:
  2604.  
  2605.     foo ( q ++ , q ++ ) ;
  2606.  
  2607. Where foo might be called as foo ( 0 , 1 ) or foo ( 1 , 0 ) depending
  2608. on moon phase. Anyway, since your program shouldn't be relying on
  2609. such UNDEFINED behaviour, the above allowance really isn't a problem.
  2610.  
  2611. And since we all validate our code and use ASSERTs everywhere and
  2612. step through it at the instruction level to verify it works right
  2613. after we wrote it (using all available documentation) this group
  2614. shouldn't have any "help me with my bug" questions either :-) :-)
  2615.  
  2616. -- 
  2617.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  2618.   "It was, in fact, cool as all get-out.  Fortunately it was a little
  2619.    too late (historically speaking) to be groovy."
  2620.                      -- Dennis Pelton
  2621.  
  2622. +++++++++++++++++++++++++++
  2623.  
  2624. >From infosafe@panix.com (Infosafe Systems)
  2625. Date: 2 Mar 1994 11:28:02 -0500
  2626. Organization: PANIX Public Access Internet and Unix, NYC
  2627.  
  2628. In article <siegelCM0vtF.9F@netcom.com>, Rich Siegel <siegel@netcom.com> wrote:
  2629. >In article <resnick-010394173234@colt-17.slip.uiuc.edu>
  2630.  resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2631. >>Here's a rash claim (flames against my ignorance welcome): Stupid
  2632.                                     ^^^^^^
  2633. >>compilers are why RISC processors do better than CISC processors. If
  2634.             ^^^ ^^^ ^^^^            ^^ ^^^^^^ ^^^^ ^^^^
  2635. >>compilers were smart enough to take advantage of all of the interesting
  2636. >>addressing modes and instructions on CISC architectures, CISCs would
  2637. >>overall be faster at running programs than RISCs. (*Duck*)
  2638.  
  2639. I'm no expert but perhaps someone here could help me out.  A few months
  2640. ago I read a longish article in Byte? (I will post the reference 
  2641. tomorrow when I am in work, if anyone is interested) about the greatness
  2642. of the MPC chip.
  2643.  
  2644. One of the topics it discussed in detail was the fact that RISC chips have
  2645. become popular, and more powerful than CISC chips for a bunch of reasons.
  2646. These included fixed instruction length to eliminate bubbles in the 
  2647. pipeline, faster instruction decode because you don't have to spend time
  2648. figuring out how long your instruction is, etc.
  2649.  
  2650. The last point that they made was that RISC has "come out on top" *because*
  2651. of improvements in compiler technology.  The article said that optimizers 
  2652. were able to make better use of RISC instructions than CISC instructions,
  2653. and this has been one of the motivating forces in developing RISC chips
  2654. for workstations, where you have *good* compilers ;-)
  2655.  
  2656. Opinions?  Let the flames begin!
  2657.  
  2658. (Again, I will post the article and a better summary, if anyone is interested)
  2659.  
  2660. Bradford Smith
  2661.  
  2662.  
  2663.  
  2664. +++++++++++++++++++++++++++
  2665.  
  2666. >From siegel@netcom.com (Rich Siegel)
  2667. Date: Wed, 2 Mar 1994 16:06:46 GMT
  2668. Organization: Bare Bones Software
  2669.  
  2670. In article <resnick-020394005117@colt-42.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2671. >In article <siegelCM0vtF.9F@netcom.com>, siegel@netcom.com (Rich Siegel) wrote:
  2672. >
  2673. >>In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2674. >>>
  2675. >>>Compilers are generally stupid. If you disassemble code resources you'll
  2676. >>>see that MPW C is stupider than THINK C, but THINK C is pretty stupid too.
  2677. >>>I am waiting for someone to release a compiler that does peep-hole
  2678. >>>optimization. Does anyone by any chance know if MetroWorks does so?
  2679. >>
  2680. >>Metrowerks does. So does THINK C. So does MPW C.
  2681. >
  2682. >Surely you're kidding. I've seen MPW C move things back and forth between
  2683. >the same two registers (or worse, to and from the stack) oodles of times
  2684. >in a series of instructions with no other side effects. THINK C constantly
  2685. >does 'MOVE.L (A7)+,D3' followed by a 'TST.L D3' followed by a branch on
  2686. >condition code. And I've never seen either of them generate a DBcc
  2687. >instruction, even when I force feed it; I have lots of code for which
  2688. >THINK C generates:
  2689. >
  2690. >    SUBQ.W #$1,D3
  2691. >    CMPI.W #$FFFF,D3
  2692. >    BNE.S  *-$000C
  2693. >
  2694. >What *are* they looking for if not these kinds of things?
  2695.  
  2696. I'm not kidding, and don't call me Shirley. :-) Don't confuse
  2697. instruction selection and target analysis with peepholing, and DBRA is
  2698. not a cure-all.  One thing that THINK C (and THINK Pascal) do pretty
  2699. well is branch-and-loop optimization (a "peephole" operation).
  2700.  
  2701. All of the above-mentioned compilers do -some- peepholing. It may not
  2702. be as thorough as you might like it, but it's done.
  2703.  
  2704. R.
  2705. -- 
  2706. Rich Siegel % siegel@netcom.com    % Principal, Bare Bones Software
  2707. --> For information about BBEdit, finger bbedit@world.std.com <--
  2708.  
  2709. "...yeah, I inhaled, and then I drank the bong water. So what're
  2710. you gonna do about it?" - Dennis Miller, on Bill Clinton
  2711.  
  2712. +++++++++++++++++++++++++++
  2713.  
  2714. >From ari@world.std.com (Ari I Halberstadt)
  2715. Date: Wed, 2 Mar 1994 17:00:16 GMT
  2716. Organization: The World Public Access UNIX, Brookline, MA
  2717.  
  2718. In article <resnick-020394005117@colt-42.slip.uiuc.edu>,
  2719. Pete Resnick <resnick@cogsci.uiuc.edu> wrote:
  2720. >condition code. And I've never seen either of them generate a DBcc
  2721. >instruction, even when I force feed it; I have lots of code for which
  2722. >THINK C generates:
  2723. >
  2724. >    SUBQ.W #$1,D3
  2725. >    CMPI.W #$FFFF,D3
  2726. >    BNE.S  *-$000C
  2727. >
  2728. >What *are* they looking for if not these kinds of things?
  2729.  
  2730. Try structure assignment in THINK C. The structure has to be big
  2731. enough, or the compiler will just use word or long word move
  2732. instructions. Here's an example of a DBF instruction:
  2733.  
  2734. static void x(void)
  2735. {
  2736.     struct { long a, b, c, d, e, f, g; } a, b;
  2737.     
  2738.     a = b;
  2739. }
  2740.  
  2741. x:
  2742. 00000000        LINK      A6,#$FFC8
  2743. 00000004        LEA       $FFE4(A6),A0
  2744. 00000008        LEA       $FFC8(A6),A1
  2745. 0000000C        MOVEQ     #$06,D0
  2746. 0000000E        MOVE.L    (A1)+,(A0)+
  2747. 00000010        DBF       D0,*-$0002     ; 0000000E
  2748. 00000014        UNLK      A6
  2749. 00000016        RTS
  2750. 0000001C
  2751.  
  2752. -- 
  2753. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  2754. "These beetles were long considered to be very rare because very few
  2755. entomologists look for beetles in the mountains, in winter, at night,
  2756. during snow storms." -- Purves W. K., et al, "Life: The Science of
  2757.  
  2758. +++++++++++++++++++++++++++
  2759.  
  2760. >From jwbaxter@olympus.net (John W. Baxter)
  2761. Date: Wed, 02 Mar 1994 10:03:00 -0800
  2762. Organization: Internet for the Olympic Peninsula
  2763.  
  2764. In article <2l2eqi$j40@panix2.panix.com>, infosafe@panix.com (Infosafe
  2765. Systems) wrote:
  2766.  
  2767. > I'm no expert but perhaps someone here could help me out.  A few months
  2768. > ago I read a longish article in Byte? (I will post the reference 
  2769. > tomorrow when I am in work, if anyone is interested) about the greatness
  2770. > of the MPC chip.
  2771. > One of the topics it discussed in detail was the fact that RISC chips have
  2772. > become popular, and more powerful than CISC chips for a bunch of reasons.
  2773. > These included fixed instruction length to eliminate bubbles in the 
  2774. > pipeline, faster instruction decode because you don't have to spend time
  2775. > figuring out how long your instruction is, etc.
  2776. > The last point that they made was that RISC has "come out on top" *because*
  2777. > of improvements in compiler technology.  The article said that optimizers 
  2778. > were able to make better use of RISC instructions than CISC instructions,
  2779. > and this has been one of the motivating forces in developing RISC chips
  2780. > for workstations, where you have *good* compilers ;-)
  2781.  
  2782. I've been around these crazy machines since around 1959 (more like 1952 if
  2783. I get to count helping mother with her "homework" with her computer usage
  2784. at JPL (she used IBM 650, ElectroData <<became part of Burroughs>> #1, IBM
  2785. 704)).
  2786.  
  2787. There have been periodic waves of RISCness, followed by retreats to
  2788. CISCness.  But the R is gradually winning...each retreat to the C direction
  2789. goes a little less far.
  2790.  
  2791. I'm beginning to thing that the current RISC wave is the real thing, and
  2792. that there won't be much retreat.  And I tend to agree that the advances in
  2793. compiler technology are a major reason why RISC may well happen this time.
  2794.  
  2795. In any case, as viewed from the late 1950s, everything we run today is
  2796. RISC.  Consider the NCR 304:  3-address instructions (add A to B putting
  2797. the result in C).  One of the interesting single machine instructions was
  2798. "write-copy-read":  write this record to that tape, read records from that
  2799. other tape and copy them to that tape until one has a key which matches
  2800. this test, and give me the matching record.  Absolutely perfect for
  2801. father-son file updates, which aren't done much any more.
  2802.  
  2803. The 304 also had single instruction in-memory sorts and merges.
  2804. -- 
  2805. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  2806.    jwbaxter@pt.olympus.net
  2807.  
  2808. +++++++++++++++++++++++++++
  2809.  
  2810. >From mxmora@unix.sri.com (Matt Mora)
  2811. Date: 2 Mar 1994 11:10:40 -0800
  2812. Organization: SRI International, Menlo Park, CA
  2813.  
  2814. In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2815.  
  2816. >Here's a rash claim (flames against my ignorance welcome): Stupid
  2817. >compilers are why RISC processors do better than CISC processors. If
  2818. >compilers were smart enough to take advantage of all of the interesting
  2819. >addressing modes and instructions on CISC architectures, CISCs would
  2820. >overall be faster at running programs than RISCs. (*Duck*)
  2821.  
  2822. I don't think could be possible. Even though its called RISC the PowerPC
  2823. chip has more instructions than the 68020 or so I've read. Its the
  2824. complexity of the instruction that matters. An instuction on a RISC takes at 
  2825. max 5 clocks, but on a CISC who knows how long a certain intruction
  2826. will take. There goes your pipelining. 
  2827.  
  2828. The beauty of RISC is its simplicity. With few transistors and less
  2829. logic, its easy to get faster CPU speeds. That's why even before the
  2830. first PowerPc mac shipped, its already be upgraded from 66 mhz to 80 mhz.
  2831. A slower running CISC will never be able to keep up. Remember the 32k
  2832. of on chip cache takes up a big chuck of the die size. Without the cache
  2833. the die would be even smaller. (but slower) CISC is doomed because
  2834. the art of writing tight fast code is becoming obsolete. If compiler
  2835. writers won't do it why should we. Image how fast things would be on RISC
  2836. with hand tuned assembly.
  2837.  
  2838.  
  2839.  
  2840.  
  2841. Xavier
  2842.  
  2843.  
  2844.  
  2845. -- 
  2846. ___________________________________________________________
  2847. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  2848. SRI International                       mxmora@unix.sri.com
  2849. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  2850.  
  2851. +++++++++++++++++++++++++++
  2852.  
  2853. >From nagle@netcom.com (John Nagle)
  2854. Date: Wed, 2 Mar 1994 19:30:41 GMT
  2855. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  2856.  
  2857. siegel@netcom.com (Rich Siegel) writes:
  2858. >In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2859. >>Compilers are generally stupid. If you disassemble code resources you'll
  2860. >>see that MPW C is stupider than THINK C, but THINK C is pretty stupid too.
  2861. >>I am waiting for someone to release a compiler that does peep-hole
  2862. >>optimization. Does anyone by any chance know if MetroWorks does so?
  2863.  
  2864. >Metrowerks does. So does THINK C. So does MPW C.
  2865.  
  2866.       But SC++ doesn't, judging from the code.
  2867.  
  2868. >>Here's a rash claim (flames against my ignorance welcome): Stupid
  2869. >>compilers are why RISC processors do better than CISC processors. If
  2870. >>compilers were smart enough to take advantage of all of the interesting
  2871. >>addressing modes and instructions on CISC architectures, CISCs would
  2872. >>overall be faster at running programs than RISCs. (*Duck*)
  2873.  
  2874. >I have a reality adjustment for you. On the 68020, many of the fancy
  2875. >addressing modes are either a wash or are actually slower than an
  2876. >equivalent sequence of instructions using 68000-only addressing modes.
  2877.  
  2878.       That's a problem with many machines with variable-length
  2879. instructions.  Check the timings for the 68030 and '040, though;
  2880. the ratios get better as you throw more transistors at the problem.
  2881.  
  2882.                           John Nagle
  2883.  
  2884. +++++++++++++++++++++++++++
  2885.  
  2886. >From jvp@tools1.ee.iastate.edu (Jim Van Peursem)
  2887. Date: 2 Mar 94 21:24:34 GMT
  2888. Organization: Iowa State University, Ames, Iowa
  2889.  
  2890. In <2l2obg$fca@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes:
  2891.  
  2892. >In article <resnick-010394173234@colt-17.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  2893.  
  2894. >>Here's a rash claim (flames against my ignorance welcome): Stupid
  2895. >>compilers are why RISC processors do better than CISC processors. If
  2896. >>compilers were smart enough to take advantage of all of the interesting
  2897. >>addressing modes and instructions on CISC architectures, CISCs would
  2898. >>overall be faster at running programs than RISCs. (*Duck*)
  2899.  
  2900. >I don't think could be possible. Even though its called RISC the PowerPC
  2901. >chip has more instructions than the 68020 or so I've read. Its the
  2902. >complexity of the instruction that matters. An instuction on a RISC takes at 
  2903. >max 5 clocks, but on a CISC who knows how long a certain intruction
  2904. >will take. There goes your pipelining. 
  2905.  
  2906.   Ah yes, the wandering definition of RISC. I saw a nice summary of
  2907. what RISC means in comp.arch awhile back. It's more a function of
  2908. cycles-per-instruction and number of registers, etc than the number
  2909. of instructions supported.
  2910.  
  2911.   I agree with Pete that originally, RISC was driven by the fact that
  2912. most compilers simply didn't support the complex instructions in some
  2913. chips. But more accurately, some complex instructions in some chips were
  2914. slower than their counter-part simple instructions to perform the same
  2915. task. The VAX had several of these as I recall. Anyway, your definition
  2916. of RISC taking a max 5 clock cycles is wrong. That depends on the depth
  2917. of the pipe and other factors.
  2918.  
  2919. >The beauty of RISC is its simplicity. With few transistors and less
  2920. >logic, its easy to get faster CPU speeds. That's why even before the
  2921. >first PowerPc mac shipped, its already be upgraded from 66 mhz to 80 mhz.
  2922.  
  2923.   But these days, the RISC processors have around the same number of
  2924. transistors as their CISC counterparts. It's more a function of the
  2925. regularity of the instructions. Since all instructions are the same
  2926. size, and decode the same, it's easy to pipeline them and keep the
  2927. pipe full.
  2928.  
  2929.   I say the reason RISC is winning the game now is because of the
  2930. advancements in both the pipelines and compilers.
  2931.  
  2932. >Image how fast things would be on RISC
  2933. >with hand tuned assembly.
  2934.  
  2935.   It would be slower. :) Remembering all of the pipeline hazards
  2936. by hand is very complex. A compiler can do a much better job of
  2937. these kinds of scheduling issues for any reasonably sized routine.
  2938.  
  2939. +---------------------------------------------------------------+
  2940. | Jim Van Peursem - Ph.D. Candidate - Ham Radio -> KE0PH        |
  2941. | Department of Electrical Engineering and Computer Engineering |
  2942. | Iowa State University - Ames, IA 50011 : (515) 294-8339       |
  2943. | internet - jvp@iastate.edu  -or-  jvp@cpre1.ee.iastate.edu    |
  2944. +---------------------------------------------------------------+
  2945.  
  2946. +++++++++++++++++++++++++++
  2947.  
  2948. >From jim@brunner.wf.com (Jim Brunner)
  2949. Date: 2 Mar 94 02:57:28 GMT
  2950. Organization: (none)
  2951.  
  2952.  
  2953. In article <resnick-010394173234@colt-17.slip.uiuc.edu>, you write:
  2954. > Here's a rash claim (flames against my ignorance welcome): Stupid
  2955. > compilers are why RISC processors do better than CISC processors. If
  2956. > compilers were smart enough to take advantage of all of the interesting
  2957. > addressing modes and instructions on CISC architectures, CISCs would
  2958. > overall be faster at running programs than RISCs. (*Duck*)
  2959.  
  2960. Actually, good RISC compilers are MORE difficult because of the difficulty 
  2961. of doing pipeline optimization.
  2962. - -
  2963. Jim Brunner (jim@brunner.wf.com)
  2964.  
  2965. +++++++++++++++++++++++++++
  2966.  
  2967. >From jtbell@cs1.presby.edu (Jon Bell)
  2968. Date: Wed, 2 Mar 94 23:06:40 GMT
  2969. Organization: Presbyterian College, Clinton, South Carolina USA
  2970.  
  2971. In article <gregor.1112919817C@ra.nrl.navy.mil>,
  2972. joe gregor <gregor@nrlfs1.nrl.navy.mil> wrote:
  2973. >In Article <2kueq8$865@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au
  2974. >(Peter N Lewis) wrote:
  2975. >
  2976. >>C or Pascal produce about teh same quality code.  It's generally about
  2977. >>half the speed of reasonably tight assembly code...
  2978. >
  2979. >    I had always heard/read that C was the fastest language next to asm.
  2980. >I *never* heard/read that Pascal was even close, let alone faster. Please
  2981. >identify your references so I may (re)educate myself.
  2982.  
  2983. It makes no sense to talk about the "speed" of a language (or rather, its
  2984. compiled code) without reference to the compiler and the computer it's
  2985. running on.  There is nothing intrinsic in the design of Pascal or C that
  2986. would make one faster than the other.  What counts is the implementation.  
  2987.  
  2988. On some computers, C is indeed much faster than Pascal because their C
  2989. compilers are more "efficient" in that respect than their Pascal
  2990. compilers.  On the Mac, this is not the case.  The two languages run just
  2991. about neck and neck when you compare (say) Think Pascal with Think C or
  2992. MPW Pascal with MPW C. 
  2993.  
  2994. I don't have specific references handy, but I'll browse through my back
  2995. issues of MacTutor and see if I can find something to post if no one beats
  2996. me to it.  
  2997.  
  2998. -- 
  2999. Jon Bell <jtbell@presby.edu>                        Presbyterian College
  3000. Dept. of Physics and Computer Science        Clinton, South Carolina USA
  3001.  
  3002. +++++++++++++++++++++++++++
  3003.  
  3004. >From especkma@reed.edu (Erik A. Speckman)
  3005. Date: 3 Mar 1994 06:56:45 GMT
  3006. Organization: Hellmouth-Heater Democrat
  3007.  
  3008. In article <jvp.762643474@tools1.ee.iastate.edu>,
  3009. Jim Van Peursem <jvp@tools1.ee.iastate.edu> wrote:
  3010. >  I agree with Pete that originally, RISC was driven by the fact that
  3011. >most compilers simply didn't support the complex instructions in some
  3012. >chips. But more accurately, some complex instructions in some chips were
  3013. >slower than their counter-part simple instructions to perform the same
  3014. >task. The VAX had several of these as I recall. Anyway, your definition
  3015. >of RISC taking a max 5 clock cycles is wrong. That depends on the depth
  3016. >of the pipe and other factors.
  3017.  
  3018. No, no, no its that implimenting complex instructions costs silicon that 
  3019. could be better used increacing pipeline complexity or chache and 
  3020. speeding up all operations.
  3021.  
  3022. No, its a desert topping.
  3023.  
  3024. No, it is all those things and a desert topping to boot.
  3025.  
  3026.  >
  3027. --
  3028. ____________________________________________________________________________
  3029. Erik Speckman            especkma@romulus.reed.edu            GBDS
  3030.  
  3031. Workstation- A high-performance microcomputer designed to run benchmarks.
  3032.  
  3033. +++++++++++++++++++++++++++
  3034.  
  3035. >From rang@winternet.mpls.mn.us (Anton Rang)
  3036. Date: 03 Mar 1994 14:37:47 GMT
  3037. Organization: Minnesota Angsters
  3038.  
  3039. In article <resnick-280294222515@colt-19.slip.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  3040. >In article <2kueq8$865@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au
  3041. >(Peter N Lewis) wrote:
  3042. >
  3043. >>>What's the best way to optimize C?
  3044. >>
  3045. >>Don't use any pointers.  Pointers screw up optimizing compilers.
  3046. >
  3047. >What?!?! Sometimes using pointers is the only way to get a really stupid
  3048. >compiler to do register allocation and register loading properly.
  3049.  
  3050.   Yes, but if you have a really *smart* compiler, pointers screw it up
  3051. royally, especially if you are passing parameters around by address.
  3052. Once you take the address of an object, almost any access through a
  3053. pointer stops the compiler from being able to optimize it.  So you're
  3054. often better off to use a temporary variable, like --
  3055.  
  3056.     temp_x = x;
  3057.     do_something(&temp_x);
  3058.     x = temp_x;
  3059.  
  3060. and keep 'x' local, so the compiler can (a) keep it in a register, and
  3061. (b) assume that its value isn't changed by almost *every* call and
  3062. every assignment through a pointer.
  3063.  
  3064. Of course, using the best algorithms is still the best way to optimize
  3065. *any* language.
  3066.  
  3067. -- Anton
  3068. --
  3069. Anton Rang (rang@acm.org)
  3070.  
  3071. +++++++++++++++++++++++++++
  3072.  
  3073. >From Brad Koehn <koehn@macc.wisc.edu>
  3074. Date: 4 Mar 1994 01:58:54 GMT
  3075. Organization: University of Wisconsin
  3076.  
  3077. In article <2l17nk$1ku@ncrpda.curtin.edu.au> Peter N Lewis,
  3078. peter@ncrpda.curtin.edu.au writes:
  3079. >Try it and see for yourself.  Pascal compilers will generally produce
  3080. faster
  3081. >code than C compilers with equivalent source.  Obviously, compilers vary
  3082. >a great deal, but the above is generally true.  I wouldn't worry though,
  3083. >I expect the next generation of compilers will make C faster than Pascal,
  3084. >since Pascal compilers will get a lot less work done on them.  Of course,
  3085. >then everyone will be using C++ and efficiency will be thrown right out
  3086. >the window, but such is life ;-)
  3087.  
  3088. Heck, check out the XLC and XLC++ compilers from IBM. Talk about
  3089. well-built! From what I understand, Apple was using them for quite a
  3090. while to compile for PPC (ahh, MPW, you dog you).
  3091.  
  3092. Anyway, these two beasties can do some really nice magic with your code.
  3093. And IBM just keeps improving them. Now, if only the Mac had it so good...
  3094. Oh, that's right, PowerOpen lets me use both AIX and MAS on the same
  3095. machine! So I can use XLC++ with my Mac code! Life is so good!
  3096. _________________________________________________________________________
  3097. Brad Koehn          Data Transformations, Inc.        koehn@macc.wisc.edu
  3098.  
  3099. +++++++++++++++++++++++++++
  3100.  
  3101. >From Brad Koehn <koehn@macc.wisc.edu>
  3102. Date: 4 Mar 1994 02:06:09 GMT
  3103. Organization: University of Wisconsin
  3104.  
  3105. In article <RANG.94Mar3083747@icicle.winternet.mpls.mn.us> Anton Rang,
  3106. rang@winternet.mpls.mn.us writes:
  3107. >  Yes, but if you have a really *smart* compiler, pointers screw it up
  3108. >royally, especially if you are passing parameters around by address.
  3109. >Once you take the address of an object, almost any access through a
  3110. >pointer stops the compiler from being able to optimize it.  So you're
  3111. >often better off to use a temporary variable, like --
  3112. >
  3113. >    temp_x = x;
  3114. >    do_something(&temp_x);
  3115. >    x = temp_x;
  3116. >
  3117. >and keep 'x' local, so the compiler can (a) keep it in a register, and
  3118. >(b) assume that its value isn't changed by almost *every* call and
  3119. >every assignment through a pointer.
  3120.  
  3121. Can't the compiler just check the code for do_something and see if it
  3122. changes temp_x? I realize it would be a real pain for compilers, but so
  3123. what? Life is pain. Anyone who tells you otherwise is trying to sell you
  3124. something.* Just build a table for each function that checks to see if
  3125. the parameters are changed. Sigh. I guess I should have taken that
  3126. compiler class...
  3127.  
  3128. * The Man in Black, "The Princess Bride"
  3129. _________________________________________________________________________
  3130. Brad Koehn          Data Transformations, Inc.        koehn@macc.wisc.edu
  3131.  
  3132. +++++++++++++++++++++++++++
  3133.  
  3134. >From pottier@prao.ens.fr (Francois Pottier)
  3135. Date: 4 Mar 1994 14:26:33 GMT
  3136. Organization: Ecole Normale Superieure, PARIS, France
  3137.  
  3138. In article <2l652h$aa6@news.doit.wisc.edu>,
  3139. Brad Koehn  <koehn@macc.wisc.edu> wrote:
  3140.  
  3141. >>    temp_x = x;
  3142. >>    do_something(&temp_x);
  3143. >>    x = temp_x;
  3144.  
  3145. >Can't the compiler just check the code for do_something and see if it
  3146. >changes temp_x? I realize it would be a real pain for compilers, but so
  3147.  
  3148. No, it can't. This looks like a typical undecidable problem. In a language
  3149. with pointers like C or Pascal, there are tons of ways of modifying a
  3150. variable. For instance, look at this:
  3151.  
  3152.   long x, y;
  3153.   long *p;
  3154.  
  3155.   p = &x;
  3156.   p++;
  3157.   *p = 0;
  3158.  
  3159. This code modifies y. Hard to tell, uh ?
  3160.  
  3161. I think it should be relatively easy to demonstrate that the problem
  3162. is undecidable. I could try writing a proof if you wish.
  3163.  
  3164. -- 
  3165. Francois Pottier            ___ ___  _    _  / ___  ___    ___
  3166. pottier@dmi.ens.fr       /_  /__/ /_|  /| / /  / /  / / /__
  3167.               /   / \  /  | / |/ /___ /__/ / ___/ _
  3168.                           /
  3169.  
  3170. +++++++++++++++++++++++++++
  3171.  
  3172. >From mmorgan@gpu.srv.ualberta.ca (Martin Morgan)
  3173. Date: 4 Mar 1994 16:02:53 GMT
  3174. Organization: University of Alberta
  3175.  
  3176. Francois Pottier (pottier@prao.ens.fr) wrote:
  3177. : Brad Koehn  <koehn@macc.wisc.edu> wrote:
  3178. : >>    temp_x = x;
  3179. : >>    do_something(&temp_x);
  3180. : >>    x = temp_x;
  3181. : >Can't the compiler just check the code for do_something and see if it
  3182. : >changes temp_x? I realize it would be a real pain for compilers, but so
  3183. : No, it can't. This looks like a typical undecidable problem. In a language
  3184.  
  3185. or the user declare do_something as do_something (const type-of-x *)?. Is
  3186. that a legal declaration?
  3187.  
  3188. : variable. For instance, look at this:
  3189. :   long x, y;
  3190. :   long *p;
  3191. :   p = &x;
  3192. :   p++;
  3193. :   *p = 0;
  3194. : This code modifies y. Hard to tell, uh ?
  3195.  
  3196. surely memory allocation of x and y is left to the compiler, so there's no
  3197. guarantee that anything relevant to the snippet is modified by *p = 0?
  3198.  
  3199. Martin Morgan
  3200.  
  3201.  
  3202.  
  3203. +++++++++++++++++++++++++++
  3204.  
  3205. >From rang@winternet.mpls.mn.us (Anton Rang)
  3206. Date: 05 Mar 1994 15:44:45 GMT
  3207. Organization: Minnesota Angsters
  3208.  
  3209. In article <2l652h$aa6@news.doit.wisc.edu> Brad Koehn <koehn@macc.wisc.edu> writes:
  3210. >>    temp_x = x;
  3211. >>    do_something(&temp_x);
  3212. >>    x = temp_x;
  3213. >
  3214. >Can't the compiler just check the code for do_something and see if it
  3215. >changes temp_x? I realize it would be a real pain for compilers, but so
  3216. >what?
  3217.  
  3218.   Yes and no.  The problem is that C's separate compilation model
  3219. calls for "compile a bunch of functions so that they all work
  3220. correctly independently; at link time, hook them together."  To make
  3221. this work right, you need to defer code generation until linking.
  3222. There are Ada development systems which do this (they need to generate
  3223. extremely tight code for embedded systems).
  3224.  
  3225.   However, because of C's ubiquitous pointers, this trick only works
  3226. for very simple functions.  Figuring out what variables a given
  3227. procedure call might modify, or even an approximation to it, in the
  3228. presence of globals or structures containing pointers, is non-trivial.
  3229. --
  3230. Anton Rang (rang@acm.org)
  3231.  
  3232. +++++++++++++++++++++++++++
  3233.  
  3234. >From zstern@adobe.com (Zalman Stern)
  3235. Date: Mon, 7 Mar 1994 02:50:34 GMT
  3236. Organization: Adobe Systems Incorporated
  3237.  
  3238. Anton Rang writes
  3239. >   Yes and no.  The problem is that C's separate compilation model
  3240. > calls for "compile a bunch of functions so that they all work
  3241. > correctly independently; at link time, hook them together."  To make
  3242. > this work right, you need to defer code generation until linking.
  3243. > There are Ada development systems which do this (they need to generate
  3244. > extremely tight code for embedded systems).
  3245.  
  3246. MIPS' C compiler/linker and the Plan 9 C compiler/linker (from AT&T Bell  
  3247. Labs) both offer link time code generation and optimization. I'm sure there  
  3248. are others. (Part of the problem with discussing a topic like this in the  
  3249. Mac community is most Mac programmers have limited experience with the broad  
  3250. realm of tools that run on other platforms.) I'd be happy with a Mac C  
  3251. compiler that was up to the state-of-the-art with regard to intra-procedure  
  3252. optimization. (Though I insist on automatic inlining of appropriate file  
  3253. scope static functions.)
  3254. --
  3255. Zalman Stern           zalman@adobe.com            (415) 962 3824
  3256. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  3257. "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)
  3258.  
  3259. +++++++++++++++++++++++++++
  3260.  
  3261. >From armb@setanta.demon.co.uk (Alan Braggins)
  3262. Date: Mon, 7 Mar 1994 17:22:02 GMT
  3263. Organization: Setanta Software
  3264.  
  3265. In article <2l7m3d$jil@quartz.ucs.ualberta.ca> mmorgan@gpu.srv.ualberta.ca (Martin Morgan) writes:
  3266.    : >Can't the compiler just check the code for do_something and see if it
  3267.    : >changes temp_x? I realize it would be a real pain for compilers, but so
  3268.  
  3269.    : No, it can't. This looks like a typical undecidable problem. In a language
  3270.  
  3271.    or the user declare do_something as do_something (const type-of-x *)?. Is
  3272.    that a legal declaration?
  3273.  
  3274. It is. But do_something is allowed to cast away const with
  3275. implementation defined results.
  3276. --
  3277. Alan Braggins  armb@setanta.demon.co.uk  abraggins@cix.compulink.co.uk
  3278. "Any technology distinguishable from magic is insufficiently advanced"
  3279.  
  3280. +++++++++++++++++++++++++++
  3281.  
  3282. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  3283. Date: 9 Mar 1994 11:41:15 +0800
  3284. Organization: NCRPDA, Curtin University
  3285.  
  3286. scott.m.silver@dartmouth.edu (Scott M. Silver) writes:
  3287.  
  3288. >All the books I've read about RISC say this is true.  I think this is
  3289. >from the standpoint that it is also easier to optimize for RISC chips
  3290. >because there aren't 9 million addressing modes, and eighty different
  3291. >ways to do things.
  3292.  
  3293. Yep, it was great writing an optimizing compiler for the ARM (Acorn
  3294. RISC Machine) (now used in the Newton).  We'd sit down and look at the
  3295. code it produced and we could come up with a thousand different ways of
  3296. doing the same thing, and they all took exactly the same amount of time!
  3297. Very nice.  Much more pleasant than sitting down with a 68040 manual and
  3298. spending several days comparing timing before deciding that it's non-
  3299. deterministic ;-)
  3300.    Peter.
  3301. -- 
  3302. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  3303.  
  3304. +++++++++++++++++++++++++++
  3305.  
  3306. >From tom@wcc.oz.au (Tom Evans)
  3307. Date: 10 Mar 94 09:05:12 GMT
  3308. Organization: Webster Computer Corp, Melbourne, Australia
  3309.  
  3310. In article <2kueq8$865@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au (Peter N Lewis) surprisingly writes:
  3311. > mfi@i-link.com (MicroFrontier Inc.) writes:
  3312. > >And....which compiler (MPW C, Symantec C, or Metrowerks C) do you think
  3313. > >produces the fastest C code (with all optimization turned on)? Which do
  3314.  
  3315. Don't run MPW C (V3.3) with "-opt full" - it can't even printf() if you do!
  3316.  
  3317. > No idea, they are probably all withing 10% (as is Pascal, normally on
  3318. > the faster side).
  3319.  
  3320. I wish it were so Peter, but it ain't, not unless they're all within
  3321. 10% of being 30% slower than they should be.
  3322.  
  3323. I compile on a Macintosh under MPW and on a Sun 3 under its compiler
  3324. or gcc. The Mac is a 33MHz 68030. The Sun is a 20MHz 68020. When I
  3325. benchmark them against each other, they always run at about the SAME
  3326. SPEED. 
  3327.  
  3328. The Sun compiles the following:
  3329.  
  3330.     void testcopy(char *p1, char *p2, short length)
  3331.     {
  3332.             while (length--)
  3333.                     *p1++ = *p2++;
  3334.     }
  3335. To:
  3336.     testcopy:                linkw   a6,#-0x10
  3337.     testcopy+4:              movl    a6@(0xc),a0
  3338.     testcopy+8:              movl    a6@(8),a1
  3339.     testcopy+0xc:            movw    a6@(0x12),d0
  3340.     testcopy+0x10:           bras    _memcpy+0x14
  3341.     testcopy+0x12:           movb    a0@+,a1@+
  3342.     testcopy+0x14:           dbra    d0,_memcpy+0x12
  3343.     testcopy+0x18:           unlk    a6
  3344.     testcopy+0x1a:           rts
  3345.  
  3346. This is pretty much exactly as an assembler programmer might do it
  3347. (but a real assembler programmer would unroll the loop, as would a
  3348. real C programmer :-).
  3349.  
  3350. MPW with optimisation on makes the following botch of it:
  3351.  
  3352.     00000000: LINK       A6,#$0000
  3353.     00000004: MOVEM.L    D7/A3/A4,-(A7)
  3354.     00000008: MOVE.W     $0012(A6),D7
  3355.     0000000C: MOVEA.L    $000C(A6),A3
  3356.     00000010: MOVEA.L    $0008(A6),A4
  3357.     00000014: BRA.S      *+$0004             ; 00000018
  3358.     00000016: MOVE.B     (A3)+,(A4)+
  3359.     00000018: MOVE.W     D7,D0
  3360.     0000001A: SUBQ.W     #$1,D7
  3361.     0000001C: TST.W      D0
  3362.     0000001E: BNE.S      *-$0008             ; 00000016
  3363.     00000020: MOVEM.L    -$000C(A6),D7/A3/A4
  3364.     00000026: UNLK       A6
  3365.     00000028: RTS        
  3366.  
  3367. MPW has used 42 bytes of code to do what the Sun did in 28 (50% more),
  3368. and it takes 40% longer to do it. There are 2 instructions in the
  3369. Sun's inner loop, versus 5 with MPW.
  3370.  
  3371. Benchmark figures - I copied the Sun's assembler code to the Mac and
  3372. assembled it there to get the "Mac running Sun compiled" figure:
  3373.  
  3374. To run 100000 loops of the above function with "len = 10" takes:
  3375.  
  3376.     Sun running    Mac running    Mac running
  3377.     Sun compiled    Mac compiled    Sun compiled
  3378.     --------------------------------------------
  3379.     23 s        22 s        15 s
  3380.  
  3381. The Mac is 47% faster running the same binary, but only 5% faster
  3382. running the same "source". MPW generated code that takes 40% longer
  3383. to execute than the Sun-compiled code did.
  3384.  
  3385. Yes, this is a slightly contrived example (a - shock, horror,
  3386. BENCHMARK!) - it took a tiny amount of work (and knowledge) to get
  3387. the Sun to use the DBRA, and not a subtract-and-branch, but at least
  3388. it doesn't copy it before comparing.
  3389.  
  3390. However, whenever I've looked at MPW's output, I've always seen
  3391. unnecessary copying between registers, unnecessary masking, weird
  3392. testing, operations that can be done in one line of code taking 4 or
  3393. 5 lines. I've foung gcc does about the same job as the Sun compiler
  3394. does (i.e. very good).
  3395.  
  3396. Does this mean that if the Macintosh ROMs and System were recompiled with
  3397. gcc the system would be 30% smaller and 50% faster? :-)
  3398.  
  3399. > >What's the best way to optimize C?
  3400. > Don't use any pointers.  Pointers screw up optimizing compilers.
  3401.  
  3402. MPW doesn't count as an "optimising compiler" then, so it doesn't
  3403. matter :-). Use pointers in preference to array references though.
  3404.  
  3405. Back to the original question - has anyone compared MPW and Symantec
  3406. and Metrowerks (and the latest gnu port perhaps) head-on-head?
  3407. Compared code SIZE and SPEED?
  3408.  
  3409. ========================
  3410. Tom Evans  tom@wcc.oz.au
  3411. Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
  3412. Victoria, Australia 61-3-560-1100  FAX ...560-0067  A.C.N. 004 818 455
  3413.  
  3414. wcc@cup.portal.com, AppleLink: "WEBSTER.USA"
  3415. 2109 O'Toole Avenue, Suite J. San Jose, CA 95131-1338 USA
  3416. 1-408-954-8054  FAX 1-408-954-1832  AppleLink WEBSTER.USA
  3417.  
  3418. +++++++++++++++++++++++++++
  3419.  
  3420. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  3421. Date: Thu, 10 Mar 94 09:04:22 PST
  3422. Organization: Peirce Software, Inc.
  3423.  
  3424.  
  3425. In article <3731@wcc.oz.au> (comp.sys.mac.programmer), tom@wcc.oz.au (Tom Evans) writes:
  3426. > Does this mean that if the Macintosh ROMs and System were recompiled with
  3427. > gcc the system would be 30% smaller and 50% faster? :-)
  3428.  
  3429. You're assuming the "system" is written in C.  Parts are, but bigger
  3430. parts are written in plain old assembler.  Other parts are written
  3431. in Pascal.
  3432.  
  3433. Some parts are highly hand optomized to run best on the specific processor
  3434. they are destine to run on since the code lives in a ROM that won't
  3435. ever be plugged into another processor type.  BlockMove and CopyBits
  3436. come to mind.
  3437.  
  3438. I understand major parts of the system are (have been) rewritten in
  3439. C to make them portable (to PowerPC and x86).
  3440.  
  3441.  
  3442. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  3443. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  3444. --                       -- San Jose, California USA 95117
  3445. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  3446. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  3447.  
  3448. +++++++++++++++++++++++++++
  3449.  
  3450. >From s_heidri@irau32.ira.uka.de (Dietmar Heidrich)
  3451. Date: 17 Mar 1994 13:39:58 GMT
  3452. Organization: University of Karlsruhe, FRG
  3453.  
  3454. In article <gregor.1112919817C@ra.nrl.navy.mil>, gregor@nrlfs1.nrl.navy.mil (joe gregor) writes:
  3455. |> 
  3456. |>     I had always heard/read that C was the fastest language next to asm.
  3457. |> I *never* heard/read that Pascal was even close, let alone faster. Please
  3458. |> identify your references so I may (re)educate myself.
  3459.  
  3460. The implementation of a language can be fast or slow, not the language itself.
  3461. For some reasons not well understood (unless you agree with Richard Gabriel in
  3462. his JOOP article), C is widespread used and therefore gets most support efforts
  3463. (at least on other platforms).
  3464.  
  3465.  
  3466.  
  3467. --
  3468. Dietmar Heidrich, Universitaet Karlsruhe, Germany
  3469.  
  3470.  
  3471. "Die Hoffnung auf den Tod ist das einzige, was mich am Leben erhaelt."
  3472.  
  3473. ---------------------------
  3474.  
  3475. >From mbayme@bih.harvard.edu (Michael J. Bayme, M.D.)
  3476. Subject: Color Terminal Emulator
  3477. Date: Sun, 06 Mar 1994 13:37:29 -0500
  3478. Organization: Beth Israel Hospital Boston
  3479.  
  3480. Hi! I'm writing a color terminal emultor for my hospital's system - and
  3481. it's slow. I use srcCopy and lots of DrawChars - it's slow. I've seen tech
  3482. notes about a bug in system 7 that makes this sort of code run slowly. Is
  3483. this true? Are there work-arounds available.
  3484. Thanks, Michael Bayme
  3485.  
  3486. +++++++++++++++++++++++++++
  3487.  
  3488. >From leonardr@netcom.com (Leonard Rosenthol)
  3489. Date: Sun, 6 Mar 1994 20:32:26 GMT
  3490. Organization: Aladdin Systems, Inc.
  3491.  
  3492. In article <mbayme-060394133729@bayme.bih.harvard.edu>,
  3493. mbayme@bih.harvard.edu (Michael J. Bayme, M.D.) wrote:
  3494.  
  3495. > Hi! I'm writing a color terminal emultor for my hospital's system - and
  3496. > it's slow. I use srcCopy and lots of DrawChars - it's slow. I've seen tech
  3497. > notes about a bug in system 7 that makes this sort of code run slowly. Is
  3498. > this true? Are there work-arounds available.
  3499. >
  3500.    The only "problem" with System 7 and color has to do with calling
  3501. SetCtlValue() on things like scrollbars to often.  
  3502.    
  3503.    Your problem is more likely the calls to DrawChar().  Try doing some
  3504. buffering and calling DrawString() or DrawText() instead, that will speed
  3505. things up.  Also look for multiple calls to setting/resetting colors, text
  3506. mode, etc.  The things a good profiler would find.
  3507.  
  3508. Leonard
  3509. - ------------------------------------------------------------------------
  3510. Leonard Rosenthol                      Internet:       leonardr@netcom.com
  3511. Director of Advanced Technology        AppleLink:      MACgician
  3512. Aladdin Systems, Inc.                  GEnie:          MACgician
  3513.  
  3514. +++++++++++++++++++++++++++
  3515.  
  3516. >From trygve@apple.com (Trygve Isaacson)
  3517. Date: Thu, 10 Mar 1994 01:06:06 -0800
  3518. Organization: Apple Computer, Inc.
  3519.  
  3520. In article <mbayme-060394133729@bayme.bih.harvard.edu>,
  3521. mbayme@bih.harvard.edu (Michael J. Bayme, M.D.) wrote:
  3522.  
  3523. > Hi! I'm writing a color terminal emultor for my hospital's system - and
  3524. > it's slow. I use srcCopy and lots of DrawChars - it's slow. I've seen tech
  3525. > notes about a bug in system 7 that makes this sort of code run slowly. Is
  3526. > this true? Are there work-arounds available.
  3527. > Thanks, Michael Bayme
  3528.  
  3529. Fortunately, yes. Terminal emulators were among the first to hit this
  3530. problem because few other programs' performance relies on the speed of
  3531. drawing text on a colored background.
  3532.  
  3533. The solution is to use srcOr instead of srcCopy (srcOr is fast). But this
  3534. means you are responsible for filling in the background color before
  3535. drawing. So:
  3536. - First, paint the invalid area with the background color
  3537. - Then, draw the text with the foreground color using srcOr
  3538.  
  3539. Unfortunately, this two-phase drawing is visibly a bit uglier than srcCopy,
  3540. but if you spend a little extra effort to do it offscreen, it will look
  3541. even better than before.
  3542.  
  3543. While I'm yacking, here are a couple of other speed tips:
  3544.  
  3545. 1) Don't draw character by character: instead, draw an entire run of text
  3546. at a time, where a run is defined as all adjacent characters that can be
  3547. drawn with the same pen/color/style/whatever. (OK, this is obvious;
  3548. otherwise your drawing would already be intolerably slow.)
  3549.  
  3550. 2) Optimize out whitespace: move the pen instead of drawing blanks. Of
  3551. course, this assumes you can calculate the character width ahead of time,
  3552. which assumes you're using a monospaced font. Note that boldface throws a
  3553. wrench in things unless your font's bold maintains the same character width
  3554. as plain, as does our Noiro font shipped with the SNA•ps emulators.
  3555.  
  3556. 3) Optimize out areas (rows/cols) that don't need to be drawn, such as
  3557. areas outside the window update region, and areas outside the modified
  3558. data. In other words, don't let clipping do all your work for you. It's
  3559. faster to calculate what doesn't need to be drawn than to actually draw
  3560. text that will be clipped.
  3561.  
  3562. 4) When you get new data to draw, don't just invalidate and sit there
  3563. waiting for an update event; draw immediately.
  3564.  
  3565. Hmmm, that's it off the top of my head.... Good luck...
  3566.  
  3567. Trygve Isaacson
  3568. SNA•ps engineer
  3569. Apple Computer, Inc.
  3570.  
  3571. +++++++++++++++++++++++++++
  3572.  
  3573. >From msouth@BIX.com (msouth on BIX)
  3574. Date: 12 Mar 94 04:28:12 GMT
  3575. Organization: Delphi Internet Services Corporation
  3576.  
  3577.  
  3578. More terminal-emulation tips of varying usefullness:
  3579.  
  3580. 5) Don't scroll with every linefeed received. Instead, save up text
  3581. and scroll a certain number of times per second.
  3582. 5) Get complicated. Most of the CPU time is probablly being
  3583. used to scroll text up one line with every linefeed received.
  3584. Instead, save up incoming text (by drawing to offscreen bitmap?),
  3585. and scroll in three or four lines at a time. You can't see more
  3586. than 20 frames or so a second, so 60 lines a secord (for instance)
  3587. would be wasting a lot of time.  Even 5 or 10 refreshes a second
  3588. can be bearable.
  3589.  
  3590. Mike South
  3591.  
  3592. ---------------------------
  3593.  
  3594. >From warwick_j@cubldr.colorado.edu
  3595. Subject: DrawString + Ellipsis character ?
  3596. Date: Thu, 10 Mar 1994 10:35:24 GMT
  3597. Organization: University of Colorado, Boulder
  3598.  
  3599. What is the best way to draw a Str255 into a Rect, abbreviating the
  3600. string if it doesn't fit by putting an ellipsis at the end?
  3601.  
  3602. The Finder does this for its By Name views, for example, when one of the
  3603. fields doesn't fit into the space provided. I seem to remember seeing a
  3604. routine to do this documented somewhere.
  3605.  
  3606. Obviously it would be simple to write, but I'd hate to reinvent the
  3607. wheel...
  3608.  
  3609. Nick.
  3610.  
  3611. +++++++++++++++++++++++++++
  3612.  
  3613. >From Lars.Farm@nts.mh.se (Lars Farm)
  3614. Date: Thu, 10 Mar 1994 14:34:24 +0100
  3615. Organization: Mid Sweden University
  3616.  
  3617. In article <1994Mar10.033524.1@cubldr.colorado.edu>,
  3618. warwick_j@cubldr.colorado.edu wrote:
  3619.  
  3620. > What is the best way to draw a Str255 into a Rect, abbreviating the
  3621. > string if it doesn't fit by putting an ellipsis at the end?
  3622.  
  3623. Use the Script Manager routine TruncString() or TruncText().
  3624. See: TextUtils.h or Script.h
  3625.  
  3626. -- 
  3627. Lars.Farm@nts.mh.se
  3628.  
  3629. +++++++++++++++++++++++++++
  3630.  
  3631. >From harveyj@dunx1.ocs.drexel.edu. (John Harvey)
  3632. Date: Thu, 10 Mar 1994 16:36:04 GMT
  3633. Organization: Drexel University
  3634.  
  3635. In article <1994Mar10.033524.1@cubldr.colorado.edu>
  3636. warwick_j@cubldr.colorado.edu writes:
  3637.  
  3638. > What is the best way to draw a Str255 into a Rect, abbreviating the
  3639. > string if it doesn't fit by putting an ellipsis at the end?
  3640.  
  3641. Use either of these two traps:
  3642.  
  3643. FUNCTION TruncText (width: Integer; textPtr: Ptr; 
  3644.                           VAR length: Integer; 
  3645.                           truncWhere: TruncCode): Integer;
  3646.  
  3647. or 
  3648.  
  3649. FUNCTION TruncString (width: Integer; VAR theString: Str255; 
  3650.                              truncWhere: TruncCode): Integer;
  3651.  
  3652. They both will return a hunk of text which will fit in the width
  3653. specified and has the correct truncation symbol(internationally
  3654. speaking).  IM-Text 5-71 to 5-72 has the details.
  3655.  
  3656. John Harvey 
  3657.  
  3658. +++++++++++++++++++++++++++
  3659.  
  3660. >From mgr@aggroup.aggroup.com (Mike Russell)
  3661. Date: Thu, 10 Mar 1994 12:44:02 -0800
  3662. Organization: the ag group, inc.
  3663.  
  3664. In article <1994Mar10.033524.1@cubldr.colorado.edu>,
  3665. warwick_j@cubldr.colorado.edu wrote:
  3666.  
  3667. > What is the best way to draw a Str255 into a Rect, abbreviating the
  3668. > string if it doesn't fit by putting an ellipsis at the end?
  3669.  
  3670. Here's some code that tries to use condensed text, then truncates the
  3671. center of the string.
  3672.  
  3673. - --
  3674.  
  3675. /*
  3676.  * shoehorn - shrink a name to the specified width by first setting
  3677. condensed text
  3678.  *                  face, then deleting letters from the middle.  Returns the value
  3679.  *                  of StringWidth().  Returns the final width.
  3680.  *
  3681.  *                   Face is not altered if it is already nonzero.
  3682.  */
  3683. int
  3684. shoehorn(StringPtr name, int *face, int w)
  3685. {
  3686.     int extra = (*face & italic)?CharWidth(' '):0;
  3687.     int ww;
  3688.     int elipsis = 0;
  3689.     Ptr p;
  3690.     
  3691.     while(name[0] > 1 && (ww=StringWidth(name) + extra) > w) {
  3692.         if(!name[0] || !w) return ww;
  3693.         if(!(*face & condense)) {
  3694.             TextFace(*face |= condense);
  3695.         } else {
  3696.             if(!elipsis)
  3697.                 name[elipsis = name[0]/2] = '…';
  3698.             p = (Ptr)name + elipsis + 1;
  3699.             if(elipsis > name[0]/2) {
  3700.                 p -= 2;
  3701.                 elipsis--;
  3702.             }
  3703.             BlockMove(p+1, p, name[0] - (p - (Ptr)name));
  3704.             name[0]--;
  3705.         }
  3706.     }
  3707.     return ww;
  3708. }
  3709.  
  3710. +++++++++++++++++++++++++++
  3711.  
  3712. >From harveyj@dunx1.ocs.drexel.edu. (harveyj)
  3713. Date: Mon, 14 Mar 1994 16:08:54 GMT
  3714. Organization: Drexel University, Office Of Computing Services
  3715.  
  3716. In article <B.Kobben-140394142336@karto516.frw.ruu.nl>
  3717. B.Kobben@frw.ruu.nl (Barend Kobben) writes:
  3718.  
  3719. > I have not got IM-Text (yet), but Trunctext and Truncstring aren't in Think
  3720. > Reference either. Could this be correct? Anyway, do these functions work if
  3721. > I want to offer sys 6 compatibility?
  3722.  
  3723. I don't own a paper copy of IM-Text myself, but I'm getting by with
  3724. copies on CD's that are lying around my place of work.  
  3725.  
  3726. Anyway, TruncText and TruncString  are not available prior to 7.0
  3727. script manager.  If you want to do the right thing internationally on
  3728. systems earlier than 7.0 you need to dig the ellipsis character out of
  3729. the 'itl4' resource's untoken table  yourself and then measure your
  3730. text to figure out where to put the ellipsis character.  IM-Text has
  3731. some example code for finding the token table and retrieving the
  3732. desired character.  Here it is (I know it is in Pascal, blame IM-Text
  3733. not me):
  3734.  
  3735. PROCEDURE MyMapTokenToString(theScript: ScriptCode; theToken: Integer;
  3736. VAR theString: Str255);
  3737.  
  3738. VAR
  3739.     itlHandle:                        Handle;
  3740.     untokenOffset:                        LongInt;
  3741.     untokenLength:                        LongInt;
  3742.     untokenPtr:                        UntokenTablePtr;
  3743.     untokenStringPtr:                        StringPtr;
  3744.  
  3745. BEGIN
  3746.     GetIntlResourceTable(theScript, smUnTokenTable, itlHandle, 
  3747.                                 untokenOffset, untokenLength);
  3748.     
  3749.     IF itlHandle = NIL THEN                                    {handle errors, return null string}
  3750.         theString := ''
  3751.     ELSE BEGIN                                    {make untokenPtr point to the }
  3752.                                         { beginning of the untoken table}
  3753.         untokenPtr := UntokenTablePtr(LongInt(itlHandle^) + 
  3754.                             untokenOffset);
  3755.         IF theToken > untokenPtr^.lastToken THEN                                                        {this token is
  3756. }
  3757.                                                             { not in table-- } 
  3758.             theString := ''                                                { return null string}
  3759.         ELSE BEGIN                                {index[theToken] is the offset }
  3760.                                         { of the desired string from the }
  3761.                                         { beginning of the untoken table}
  3762.             untokenStringPtr := StringPtr(LongInt(untokenPtr)            
  3763.                                +untokenPtr^.index[theToken]);
  3764.             theString := untokenStringPtr^;
  3765.         END;
  3766.     END;
  3767.  
  3768. I'll leave the measuring code and inserting the character to the reader
  3769. (there was another posting which provided code to do that, I think).
  3770.  
  3771. Of course, if you don't mind the ellipsis character turning into a
  3772. hiragana character on a Japanese system ( and other things on other
  3773. non-roman systems), the easiest thing to do is just hardwire the
  3774. ellipsis character.  
  3775.  
  3776. If you worry much about text on the Mac then IM-Text is a pretty
  3777. important investment.  Stuff that was scattered everywhere is finally
  3778. together in one book, and questions about when features are available
  3779. are easily answered. 
  3780.  
  3781. Sorry, I didn't include a mention of 6.0 compatibility before.
  3782.  
  3783. John Harvey
  3784.  
  3785.  
  3786. +++++++++++++++++++++++++++
  3787.  
  3788. >From Lars.Farm@nts.mh.se (Lars Farm)
  3789. Date: Tue, 15 Mar 1994 10:43:13 +0100
  3790. Organization: Mid Sweden University
  3791.  
  3792. In article <1994Mar14.160854.3349@netnews.noc.drexel.edu>,
  3793. harveyj@dunx1.ocs.drexel.edu. (harveyj) wrote:
  3794.  
  3795. > Anyway, TruncText and TruncString  are not available prior to 7.0
  3796. > script manager.  
  3797.  
  3798. They were introduced in 6.0.3 or 6.0.4 I think, with Upr/LwrText and others
  3799. in the script manager.
  3800.  
  3801. Lars
  3802.  
  3803. -- 
  3804. Lars.Farm@nts.mh.se
  3805.  
  3806. +++++++++++++++++++++++++++
  3807.  
  3808. >From harveyj@dunx1.ocs.drexel.edu. (harveyj)
  3809. Date: Tue, 15 Mar 1994 13:11:49 GMT
  3810. Organization: Drexel University, Office Of Computing Services
  3811.  
  3812. In article <Lars.Farm-150394104313@sleipner.nts.mh.se>
  3813. Lars.Farm@nts.mh.se (Lars Farm) writes:
  3814.  
  3815. > They were introduced in 6.0.3 or 6.0.4 I think, with Upr/LwrText and others
  3816. > in the script manager.
  3817.  
  3818. I sound like a parrot with this IM-Text stuff, but table 6-1 on page
  3819. 6-6 of IM-Text says that TruncText and TruncString were introduced with
  3820. version 7.0 Script Manager.  Version 7.0 Script Manager was first
  3821. released with system 7.0 (table 6-2 page 6-9 of IM-Text).
  3822.  
  3823. Like Al Smith said, "Let's look at the record."  Of course, I've
  3824. apparently lost my mind to quote somebody without a reference.  But, I
  3825. think I saw the quote in _Mad Magazine_, April 1964.  OK?
  3826.  
  3827. John Harvey
  3828.  
  3829. ---------------------------
  3830.  
  3831. >From klug@genesis.nred.ma.us (Mark Pirri)
  3832. Subject: Finder comments on non-Desktop DB volumes?
  3833. Date: Fri, 11 Mar 1994 05:14:07 GMT
  3834. Organization: Genesis Public Access Unix +1 508 664 0149
  3835.  
  3836. Is it possible to read the Finder comments for files on a <2MB volume
  3837. (i.e. no Desktop database) in System 7.  I know that they're stored in the
  3838. old-style Desktop file (resource type 'FCMT' or something like that), but
  3839. since the Finder always keeps that open, how can I access them?
  3840.  
  3841. Any assistance would be greatly appreciated. 
  3842.  
  3843. Thanks in advance
  3844. -mark p
  3845. -- 
  3846. - ------------------------------\
  3847. Mark N. Pirri             \  THIS SPACE FOR RENT
  3848. internet: klug@genesis.nred.ma.us \  no corny .sig's, please!
  3849. AOL: TheVortex [@aol.com]       \  
  3850.  
  3851. +++++++++++++++++++++++++++
  3852.  
  3853. >From kd@summit.novell.com (Delbarre K.)
  3854. Date: 11 Mar 1994 20:18:40 -0500
  3855. Organization: Novell, Summit
  3856.  
  3857. In article <CMHIJK.HEw@genesis.nred.ma.us> klug@genesis.nred.ma.us (Mark Pirri) writes:
  3858. >Is it possible to read the Finder comments for files on a <2MB volume
  3859. >(i.e. no Desktop database) in System 7.  I know that they're stored in the
  3860. >old-style Desktop file (resource type 'FCMT' or something like that), but
  3861. >since the Finder always keeps that open, how can I access them? [ ... ]
  3862.  
  3863. You can open the Desktop resource file read-only using
  3864. FSpOpenResFile(spec, fsRdPerm) or some variant thereof.
  3865. TN212 says to avoid opening a resource file read-only,
  3866. because it could lead to a corrupted resource map.
  3867. If there is a safer alternative I'd love to hear about it.
  3868.  
  3869. My utility GetInfo exists primarily to allow you to save
  3870. and restore all of your comments from a System 7 Desktop
  3871. Database, but also has the capability of extracting the
  3872. comments from an old-style Desktop resource file.  It
  3873. uses FSpOpenResFile(spec, fsRdPerm) to open the resource
  3874. file for the reason you mention.
  3875. --
  3876. Kelvin Delbarre, Omicron Software Systems, Inc.
  3877. contracted to Novell's UNIX System Laboratories, Summit, NJ
  3878. kd@summit.novell.com
  3879.  
  3880. +++++++++++++++++++++++++++
  3881.  
  3882. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  3883. Date: 14 Mar 94 18:05:57 +1300
  3884. Organization: University of Waikato, Hamilton, New Zealand
  3885.  
  3886. In article <CMHIJK.HEw@genesis.nred.ma.us>, klug@genesis.nred.ma.us (Mark Pirri) writes:
  3887. > Is it possible to read the Finder comments for files on a <2MB volume
  3888. > (i.e. no Desktop database) in System 7.  I know that they're stored in the
  3889. > old-style Desktop file (resource type 'FCMT' or something like that), but
  3890. > since the Finder always keeps that open, how can I access them?
  3891.  
  3892. Here's an idea I came up with. Unfortunately, it'll only work with Finder 7.1.3
  3893. (which makes proper use of the AppleEvent Manager):
  3894.  
  3895. * Install a system handler for a custom AppleEvent.
  3896. * Send this event to the Finder, so it executes your custom event handler
  3897.   in the Finder's process context.
  3898. * Your custom handler now has full access to all the resource files the Finder
  3899.   has open, including the desktop database on <2MB volumes.
  3900.  
  3901. Now, can anyone figure out how to make this work with pre-7.1.x Finders...?
  3902.  
  3903. Lawrence
  3904. (had a lot of fun with special kernel ASTs under VAX/VMS)
  3905.  
  3906. +++++++++++++++++++++++++++
  3907.  
  3908. >From leonardr@netcom.com (Leonard Rosenthol)
  3909. Date: Tue, 15 Mar 1994 20:03:10 GMT
  3910. Organization: Aladdin Systems, Inc.
  3911.  
  3912. In article <1994Mar14.180557.26363@waikato.ac.nz>, ldo@waikato.ac.nz
  3913. (Lawrence D'Oliveiro, Waikato University) wrote:
  3914.  
  3915. > Here's an idea I came up with. 
  3916. > Unfortunately, it'll only work with Finder 7.1.3
  3917. > (which makes proper use of the AppleEvent Manager):
  3918. > * Install a system handler for a custom AppleEvent.
  3919. > * Send this event to the Finder, so it executes your custom event handler
  3920. >   in the Finder's process context.
  3921. > * Your custom handler now has full access to all the resource files the Finder
  3922. >   has open, including the desktop database on <2MB volumes.
  3923. > Now, can anyone figure out how to make this work with pre-7.1.x Finders...?
  3924.    Actually it will work JUST FINE under ANY version of System 7, since
  3925. even older versions of the Finder will end up "forwarding" on the event to
  3926. the system handlers.  
  3927.  
  3928.    In fact, this is how OSA Menu works - it sends an event to the current
  3929. process that should end up getting ignored and processed by my system
  3930. handler.
  3931.  
  3932. Leonard
  3933. - ------------------------------------------------------------------------
  3934. Leonard Rosenthol                      Internet:       leonardr@netcom.com
  3935. Director of Advanced Technology        AppleLink:      MACgician
  3936. Aladdin Systems, Inc.                  GEnie:          MACgician
  3937.  
  3938. ---------------------------
  3939.  
  3940. >From ssiegler@hns.com (Stuart Sieger)
  3941. Subject: Finding System Folder (Again)
  3942. Date: Mon, 28 Feb 1994 18:54:49 GMT
  3943. Organization: Hughes Network Systems Inc.
  3944.  
  3945.     OK, Im hopeless.
  3946.  
  3947.     I am trying to "find" the system folder so that I can put my
  3948.     preferences there...
  3949.  
  3950.     How does one go about that?  I read that FindFolder works for sys7
  3951.     only (and I still need to support sys6).  Can someone give me
  3952.     a code frag (or point me in the right direction) to locate the
  3953.     system folder (or at least locate the path-string that leads
  3954.     to the folder (ie, disk:System Folder:Preferences).
  3955.  
  3956.     Any other suggestions (other than RTFM (I already tried that))
  3957.     would be helpful.
  3958.  
  3959.     Stuart Siegler
  3960. "Just because you're paranoid doesn't mean they aren't out to get you"
  3961.  
  3962.  
  3963. +++++++++++++++++++++++++++
  3964.  
  3965. >From alana@cs.uoregon.edu (Alan Akins)
  3966. Date: 3 Mar 1994 09:19:45 -0800
  3967. Organization: The uncharted backwaters of the unfashionable end of the                  Western Spiral arm of the Galaxy.
  3968.  
  3969. In article <1994Feb28.185449.22632@hns.com>,
  3970. Stuart Sieger <ssiegler@hns.com> wrote:
  3971. >
  3972. >       I am trying to "find" the system folder so that I can put my
  3973. >       preferences there...
  3974. >
  3975. >       How does one go about that?  I read that FindFolder works for sys7
  3976. >       only (and I still need to support sys6).  Can someone give me
  3977. >       a code frag (or point me in the right direction) to locate the
  3978. >       system folder (or at least locate the path-string that leads
  3979. >       to the folder (ie, disk:System Folder:Preferences).
  3980.  
  3981. OK. Using FindFolder with System 7 is all I can help you with. I know
  3982. that glue code is supplied in THINK C for System 6 as well, but I've
  3983. never tried anything I've written with pre Sys7 systems.
  3984.  
  3985. FindFolder is doc'd in IM: Mac TB Essentials 7-54 thru 7-56 and is defined:
  3986.  
  3987. FUNCTION FindFolder( vRefNum: Integer; folderType: OSType;
  3988.                      createFolder: Boolean; VAR foundVRefNum: Integer;
  3989.                      VAR foundDirID: LongInt): OSErr;
  3990.  
  3991.  
  3992. The System Folder has constant type kSystemFolderType.  For my
  3993. example, we also depend on the system constants kOnSystemDisk and
  3994. kCreateFolder.
  3995.  
  3996. So, one would use it like this (in C):
  3997.  
  3998. long
  3999. FindSysFolder( void )
  4000. {
  4001.     long    dirID;
  4002.     short   vRefNum;
  4003.     OSErr   err;
  4004.  
  4005.     err = FindFolder( kOnSystemDisk, kSystemFolderType, kCreateFolder,
  4006.                       &vRefNum, &dirID );
  4007.     if ( err == noErr )
  4008.         return dirID;
  4009.     else
  4010.         /* Do some error recovery here */
  4011.         ;
  4012. }
  4013.  
  4014. This will look for the System Folder on the startup disk and if it is
  4015. not found, it will be created. Since it looks on the startup disk, it
  4016. should definitely be able to find it!
  4017.  
  4018. Hope this all helps!
  4019. -- 
  4020. *      "Evan's been doing parallel       |    Alan Akins                      *
  4021. *           processing for so long...    |    alana@cs.uoregon.edu            *
  4022. *                 he's beside himself."  |    University of Oregon            *
  4023. *                        - Me            |    Department of Computer Science  *
  4024.  
  4025. +++++++++++++++++++++++++++
  4026.  
  4027. >From Steve Bryan <sbryan@maroon.tc.umn.edu>
  4028. Date: Fri, 4 Mar 1994 06:20:56 GMT
  4029. Organization: Sexton Software
  4030.  
  4031. In article <1994Feb28.185449.22632@hns.com> Stuart Sieger,
  4032. ssiegler@hns.com writes:
  4033. >    only (and I still need to support sys6).  Can someone give me
  4034. >    a code frag (or point me in the right direction) to locate the
  4035. >    system folder (or at least locate the path-string that leads
  4036. >    to the folder (ie, disk:System Folder:Preferences).
  4037.  
  4038. Call SysEnvirons. This sets a variable of type SysEnvRec. One of its
  4039. fields is sysVRefNum which is a working directory refNum for the system
  4040. folder. If you need its 'real' vRefNum and dirID use sysVRefNum and a
  4041. call to PBGetWDInfo.
  4042. Steve Bryan                  InterNet: sbryan@maroon.tc.umn.edu
  4043. Sexton Software            CompuServe: 76545,527
  4044. Minneapolis, MN                   Fax: (612) 929-1799
  4045.  
  4046. ---------------------------
  4047.  
  4048. >From kurisuto@chopin.udel.edu (Sean J. Crist)
  4049. Subject: Free code:  Sean's window manager
  4050. Date: 8 Mar 1994 20:07:11 -0500
  4051. Organization: University of Delaware
  4052.  
  4053. Following is the Pascal code I mentioned on an earlier post; since a few
  4054. people have expressed an interest, I'll go ahead and post it. 
  4055.  
  4056. This is basically an extension to the Window Manager with two functions:
  4057. 1) it supports floating palettes associated with specific windows, and 2)
  4058. it helps keep track of which window is which when your application allows
  4059. the user to open any number of windows (e.g. if you're writing a word
  4060. processor which allows any number of documents to be open at once, this
  4061. code helps to tell the document windows apart from each other without
  4062. maintaining a WindowPtr to each one). 
  4063.  
  4064. Sorry that this is isn't binhexed or compressed.  This code may be freely
  4065. incorporated into shareware programs, but I reserve all other rights. 
  4066. Military use of this code is specifically prohibited.
  4067.  
  4068.  
  4069. unit SeansWindowManager;
  4070.  
  4071. {Copyright 1994 by Sean Crist (kurisuto@chopin.udel.edu).  This code may be
  4072. freely incorporated into shareware}
  4073. {or freeware projects.  All other rights reserved.}
  4074.  
  4075. {I am aware of no bugs in this code, but please send me reports of any 
  4076. bugs you find.}
  4077.  
  4078. {     What this code is for:  This is basically an extension to the 
  4079. Window Manager 1) to support floating palettes, and}
  4080. { 2) to obviate the need to keep WindowPtr's to each window.  If you are 
  4081. writing an application with a fixed number}
  4082. {of windows, you can just define your WindowPtr's as globals, but if your 
  4083. application supports arbitrary}
  4084. {numbers of windows (e.g. a word processor which allows any number of 
  4085. documents to be open at a time), it can be}
  4086. {a hassle to keep track of all of these WindowPtr's in a variable-length 
  4087. array or whatever.  The following code}
  4088. {makes it easy to manage large numbers of windows of assorted kinds. }
  4089. {     The basic strategy here is to put a handle in the RefCon of every 
  4090. window opened by your application (not only}
  4091. {your 'document' windows but also your Clipboard window, your modeless 
  4092. dialogs, etc).  This handle contains}
  4093. {information uniquely identifying the window.  You don't need to keep any 
  4094. pointers to specific windows; when you}
  4095. {want a certain window, you just call one of the routines below, giving 
  4096. information to identify the window.}
  4097. {The code below quickly looks through all the windows and gives you a 
  4098. pointer to the window you want.}
  4099. {     Of course, you need not be greatly concerned with these handles; 
  4100. just make the appropriate calls to the}
  4101. {routines below, and most of the grubby work will be done for you.}
  4102.  
  4103. {There's several changes you must make to your code, and to the code 
  4104. below, for this all to work properly:}
  4105. {1.  You must edit the list of wTypes below to reflect all the kinds of 
  4106. windows your program supports.}
  4107. {2.  You must edit the SetPrivateHilite routine below to reflect the 
  4108. relation between palettes and regular}
  4109. {      windows in a way specific to your application.  For example, if 
  4110. you want your wToolsPalette to become}
  4111. {      visible when one of you wArtWindows is selected, you should code 
  4112. this here.}
  4113. {3.  Your program's initialization routine must set the 
  4114. PrivateFrontWindow global (declared below) to some}
  4115. {      valid WindowPtr.  It doesn't matter which window this is, as long 
  4116. as it is a valid one.  The code below}
  4117. {      will change the PrivateFrontWindow in response to your calls, but 
  4118. it needs a window to start out with.}
  4119. {4.  Every time you open a new window, you must call InitializeWindow on 
  4120. it to record what kind of window it is.}
  4121. {      Just before you dispose of a window, you must call DisposeWData on 
  4122. it first.}
  4123. {5.  You must not call the Toolbox routine SelectWindow, since this will 
  4124. mess up the hiliting of windows and }
  4125. {      visibility of palettes.  Use the routine PrivateActivate (defined 
  4126. below) instead.}
  4127. {6.   In your event loop, you need to do a little extra work to support 
  4128. floating palettes. We treat a window and }
  4129. {      its palettes as one 'layer'.  When you get a mousedown in 
  4130. PrivateFrontWindow, or in one of the palettes}
  4131. {      belonging to PrivateFrontWindow, then you should just call 
  4132. BringToFront on that window.}
  4133. {      (Your event code thus needs to be smart about what kinds of 
  4134. palettes belong to what kinds }
  4135. {      of windows.)}
  4136. {      If the mousedown is in some other window (i.e. neither 
  4137. PrivateFrontWindow nor its palettes), then you should}
  4138. {      call PrivateActivate, which is much like SelectWindow except that 
  4139. it does the extra work to support floating}
  4140. {      palettes and make sure everything gets hilited properly.}
  4141.  
  4142.  
  4143. interface
  4144.  
  4145. {Window types}
  4146.  const
  4147.   wMiscWindow = 1;
  4148.   wMiscWindowWithPalette = 2;
  4149.   wMiscPalette = 3;
  4150. {These window types are just to illustrate how this code works.  In your 
  4151. program, you would want to change these}
  4152. {constants to whatever kinds of windows your program supports.  (The 
  4153. application I'm working on has about 15}
  4154. {different kinds of windows and three kinds of palettes, for example.)  
  4155. Each window type, including palettes, must}
  4156. {have a unique identifying number.}
  4157.  
  4158.  const
  4159.   BadWindow = 9999;
  4160. {For doing error checking.  We send this to our own error handlers, 
  4161. pretending it's a real Toolbox error code.}
  4162.  
  4163.  var
  4164.   PrivateFrontWindow: WindowPtr;
  4165. {This is the WindowPtr to the window that we _consider_ to be the front 
  4166. window, ignoring whatever floating palettes}
  4167. {might be in front of it in the actual window list.  Note: you must 
  4168. initialize this to some valid WindowPtr when your}
  4169. {program initializes itself, or this code will crash.}
  4170.  
  4171.  
  4172.  
  4173. {We store the following record as a handle in the RefCon field of a 
  4174. window.  It contains all of our information that}
  4175. {we need to keep track of what kind of window this is.  Most of the time, 
  4176. you'll never need to manipulate the contents}
  4177. {of this record directly, since there's more convenient routines below to 
  4178. do this work for you.}
  4179.  type
  4180.   WindowData = record
  4181.     Class: Integer;     {What kind of window or dialog?  This is one of 
  4182. the wType constants above.}
  4183.     Owner: Integer;
  4184.     Index: Integer;
  4185.     DataHandle: Handle; {Handle to whatever other data you wish to store 
  4186. for this window.}
  4187.     AuxData: Integer;   {To be used however you like.}
  4188.    end;
  4189.   WDataPtr = ^WindowData;
  4190.   WDataHandle = ^WDataPtr;
  4191. {     Note on the fields 'Class', 'Owner', and 'Index':  the Class is the 
  4192. kind of window, e.g. a Clipboard window,}
  4193. {a search-and-replace modeless dialog, or whatever.  This field contains 
  4194. one of the wType constants defined above.}
  4195. {The owner and index tell which window of that kind we are talking 
  4196. about.  In the case where there's only one }
  4197. {instance of a kind of window (such as a Clipboard window), you can just 
  4198. set Owner and Index to 0 when you call }
  4199. {InitializeWindow.  When there's more than one instance of a particular 
  4200. window type, give each window a different }
  4201. {Index to distinguish it.}
  4202. {     Under normal circumstances, you can just set Owner to 0 in all 
  4203. cases.  I include this field because my application }
  4204. {has script windows for different kinds of objects, so I need to know if 
  4205. this is, say, the script window for}
  4206. {the 7th zone or the 7th room or whatever.}
  4207.  
  4208.  
  4209.  
  4210. {Call InitializeWindow when you are opening a new window.  You are 
  4211. responsible for creating the window with}
  4212. {GetNewCWindow or GetNewDialog or whatever; pass this handle in 
  4213. WhichWindow.  InitializeWindow allocates}
  4214. {a WDataHandle, installs it in the refCon of whichWindow, and sets up the 
  4215. Class, Owner, and Index values.}
  4216.  function InitializeWindow (whichWindow: WindowPtr; Class, Owner, Index: 
  4217. Integer): Boolean;
  4218.  
  4219. {Dispose the WDataHandle associated with whichWindow.  Note:  You are 
  4220. responsible for disposing whatever}
  4221. {data you have stored in DataHandle.  The right order to dispose things 
  4222. is: 1) dispose any data of your own}
  4223. {which you've stored in DataHandle 2) call DisposeWData  3) dispose of 
  4224. the window or dialog itself with}
  4225. {the appropriate Toolbox call.}
  4226.  procedure DisposeWData (whichWindow: WindowPtr);
  4227.  
  4228. {Store this handle in DataHandle.}
  4229.  procedure SetWHandle (whichWindow: WindowPtr; TheHandle: Handle);
  4230.  
  4231. {Return the handle stored in DataHandle.}
  4232.  function GetWHandle (whichWindow: WindowPtr): Handle;
  4233.  
  4234. {Given a window, return its WDataHandle}
  4235.  function GetWData (whichWindow: WindowPtr): WDataHandle;
  4236.  
  4237. {What is the class of whichWindow?  (You could accomplish this same thing 
  4238. by calling GetWData and then}
  4239. {looking at MyWData^^.Class, but this routine saves work.)  Returns -1 if 
  4240. the WData is bad (i.e., you probably}
  4241. {didn't call InitializeWindow on this window.}
  4242.  function GetWClass (whichWindow: WindowPtr): Integer;
  4243.  
  4244. {What is the index of whichWindow?  (You could accomplish this same thing 
  4245. by calling GetWData and then}
  4246. {looking at MyWData^^.Index, but this routine saves work.)  Returns -1 if 
  4247. the WData is bad (i.e., you probably}
  4248. {didn't call InitializeWindow on this window.}
  4249.  function GetWIndex (whichWindow: WindowPtr): Integer;
  4250.  
  4251. {Search through all the windows and try to find the one which has the 
  4252. specified class, owner, and index.}
  4253.  function SearchWindow (Class, Owner, Index: Integer): WindowPtr;
  4254.  
  4255. {Same as SearchWindow, but for windows like the Clipboard which have only 
  4256. one instance.}
  4257.  function FindUniqueWindow (Class: Integer): WindowPtr;
  4258.  
  4259. {Try to bring to front the window with this class, owner, and index.  
  4260. Returns TRUE if there is no such window,}
  4261. {i.e.  the window can't be activated and must be created.  This can make 
  4262. your code succinct; when the user}
  4263. {does some action to open a particular window, your routine MyOpenWindow 
  4264. can start out 'if CantActivate}
  4265. {(the window I need) then (do whatever to open it, including calling 
  4266. InitializeWindow)'.}
  4267.  function CantActivate (Class, Owner, Index: Integer): Boolean;
  4268.  
  4269. {You should use this instead of SelectWindow.}
  4270.  procedure PrivateActivate (whichWindow: WindowPtr);
  4271.  
  4272.  
  4273. implementation
  4274.  
  4275.  procedure doOSErr (ErrorCode: Integer);
  4276.  begin
  4277. {Handle the error however you like.  I usually post an alert.}
  4278.  end;
  4279.  
  4280. {Error checking.  Make sure the WDataHandle is a valid one by checking 
  4281. its length.  This is}
  4282. {mainly for debugging.}
  4283.  function IsValidWindowHandle (TheWDataHandle: WDataHandle): Boolean;
  4284.   var
  4285.    HandleSize: LongInt;
  4286.  begin
  4287.   IsValidWindowHandle := TRUE;
  4288.   HandleSize := GetHandleSize(Handle(TheWDataHandle));
  4289.   if HandleSize <> SizeOf(WindowData) then
  4290.    IsValidWindowHandle := FALSE;
  4291.  end;
  4292.  
  4293.  
  4294.  function GetWData (whichWindow: WindowPtr): WDataHandle;
  4295.   var
  4296.    thePeek: WindowPeek;
  4297.    TheHandle: Handle;
  4298.  begin
  4299.   if WhichWindow = nil then
  4300.    begin
  4301.     doOSErr(BadWindow);
  4302.     GetWData := nil;
  4303.    end
  4304.   else
  4305.    begin
  4306.     thePeek := WindowPeek(WhichWindow);
  4307.     TheHandle := Handle(thePeek^.RefCon);
  4308.     GetWData := WDataHandle(TheHandle);
  4309.    end;
  4310.  end;
  4311.  
  4312.  
  4313.  function GetWClass (whichWindow: WindowPtr): Integer;
  4314.   var
  4315.    WData: WDataHandle;
  4316.  begin
  4317.   WData := GetWData(whichWindow);
  4318.   if IsValidWindowHandle(WData) then
  4319.    GetWClass := WData^^.Class
  4320.   else
  4321.    GetWClass := -1;
  4322.  end;
  4323.  
  4324.  
  4325.  function GetWIndex (whichWindow: WindowPtr): Integer;
  4326.   var
  4327.    WData: WDataHandle;
  4328.  begin
  4329.   WData := GetWData(whichWindow);
  4330.   if IsValidWindowHandle(WData) then
  4331.    GetWIndex := WData^^.Index
  4332.   else
  4333.    GetWIndex := -1;
  4334.  end;
  4335.  
  4336.  
  4337.  function GetWHandle (whichWindow: WindowPtr): Handle;
  4338.   var
  4339.    WData: WDataHandle;
  4340.  begin
  4341.   WData := GetWData(whichWindow);
  4342.   if IsValidWindowHandle(WData) then
  4343.    GetWHandle := WData^^.DataHandle
  4344.   else
  4345.    begin
  4346.     GetWHandle := nil;
  4347.     doOSErr(BadWindow);
  4348.    end;
  4349.  end;
  4350.  
  4351.  
  4352.  procedure SetWHandle (whichWindow: WindowPtr; TheHandle: Handle);
  4353.   var
  4354.    WData: WDataHandle;
  4355.  begin
  4356.   WData := GetWData(whichWindow);
  4357.   if IsValidWindowHandle(WData) then
  4358.    WData^^.DataHandle := TheHandle
  4359.   else
  4360.    doOSErr(BadWindow);
  4361.  end;
  4362.  
  4363.  
  4364.  
  4365.  function InitializeWindow (whichWindow: WindowPtr; Class, Owner, Index: 
  4366. Integer): Boolean;
  4367.   var
  4368.    thePeek: WindowPeek;
  4369.    WData: WDataHandle;
  4370.    OkSoFar: Boolean;
  4371.    Result: Integer;
  4372.  begin
  4373.   OkSoFar := true;
  4374.   thePeek := WindowPeek(WhichWIndow);
  4375.   WData := WDataHandle(NewHandle(SizeOf(WindowData)));
  4376.   Result := MemError;
  4377.   if Result <> 0 then
  4378.    begin
  4379.     OkSoFar := False;
  4380.     doOSErr(MemError);
  4381.    end;
  4382.  
  4383.   if OkSoFar then
  4384.    begin
  4385.     thePeek^.RefCon := LongInt(WData);
  4386.     WData^^.Class := Class;
  4387.     WData^^.Owner := Owner;
  4388.     WData^^.Index := Index;
  4389.    end;
  4390.  
  4391.   InitializeWindow := OkSoFar;
  4392.  end;
  4393.  
  4394.  
  4395.  procedure DisposeWData (whichWindow: WindowPtr);
  4396.   var
  4397.    WData: WDataHandle;
  4398.  begin
  4399.   WData := GetWData(whichWindow);
  4400.   if IsValidWindowHandle(WData) then
  4401.    DisposHandle(Handle(WData))
  4402.   else
  4403.    doOSErr(BadWindow);
  4404.  end;
  4405.  
  4406.  
  4407. {I hope this is still a kosher way to find out which window is really in 
  4408. the front!  If this is no longer}
  4409. {kosher, then I'd just make an invisible window which is always frontmost 
  4410. (a la BringToFront) and}
  4411. {use it as my starting point for the search through the linked list.}
  4412.  function findFrontWindow: WindowPtr;
  4413.   const
  4414.    WindowList = $9D6;
  4415.   type
  4416.    PtrPtr = ^Ptr;
  4417.   var
  4418.    WindowListPtr: PtrPtr;
  4419.  begin
  4420.   WindowListPtr := Pointer(WindowList);
  4421.   findFrontWindow := WindowPtr(WindowListPtr^);  {was: FrontWindow}
  4422.  end;
  4423.  
  4424.  
  4425.  function SearchWindow (Class, Owner, Index: Integer): WindowPtr;
  4426.   var
  4427.    done: boolean;
  4428.    ThisWindow, FoundWindow: WindowPtr;
  4429.    WData: WDataHandle;
  4430.    ThisWPeek: WindowPeek;
  4431.  begin
  4432.   done := false;
  4433.   FoundWindow := nil;
  4434.   ThisWindow := FindFrontWindow;
  4435.   if ThisWindow <> nil then
  4436.    while not done do
  4437.     begin
  4438.      WData := GetWData(ThisWindow);
  4439.      if IsValidWindowHandle(WData) then
  4440.       if WData^^.Class = Class then
  4441.        if WData^^.Owner = Owner then
  4442.        if WData^^.Index = Index then
  4443.        begin
  4444.        FoundWindow := ThisWindow;
  4445.        Done := true;
  4446.        end;
  4447.      if not Done then
  4448.       begin
  4449.        ThisWPeek := WindowPeek(ThisWindow);
  4450.        ThisWPeek := ThisWPeek^.nextWindow;
  4451.        ThisWindow := WindowPtr(ThisWPeek);
  4452.        if ThisWindow = nil then
  4453.        Done := true;
  4454.       end;
  4455.     end;
  4456.   SearchWindow := FoundWindow;
  4457.  end;
  4458.  
  4459.  
  4460.  function CantActivate (Class, Owner, Index: Integer): Boolean;
  4461.   var
  4462.    ThisWindow: WindowPtr;
  4463.  begin
  4464.   CantActivate := TRUE;  {Assume the window doesn't exist.}
  4465.   ThisWindow := SearchWindow(Class, Owner, Index);
  4466.   if ThisWindow <> nil then
  4467.    begin
  4468.     SelectWindow(ThisWindow);
  4469.     CantActivate := FALSE;  {The window exists, so we _can_ activate it.}
  4470.    end;
  4471.  end;
  4472.  
  4473.  function FindUniqueWindow (Class: Integer): WindowPtr;
  4474.  begin
  4475.   FindUniqueWindow := SearchWindow(Class, 0, 0);
  4476. {By convention, all unique windows have 0 and 0 as their other arguments.}
  4477.  end;
  4478.  
  4479.  procedure AutoPositionPalettes (WhichWindow: WindowPtr);
  4480.  begin
  4481. {If you want your palettes to be automatically positioned next to a 
  4482. certain kind of window, put code here}
  4483. {to move the palettes to the right position.}
  4484.  end;
  4485.  
  4486. {This internal routine is used to hilite or unhilite windows.  Note that 
  4487. there's more going on here than}
  4488. {just drawing the hiliting on the window.  For our purposes, 'hilite' 
  4489. means 'bring it to the front, hilite it,}
  4490. {and display its palettes as well'.  'Unhilite' means 'Turn off its 
  4491. hiliting, and hide its palettes also.'}
  4492.  procedure SetPrivateHilite (whichWindow: WindowPtr; Hilite: Boolean);
  4493.  begin
  4494.   if WhichWindow = nil then
  4495.    doOSErr(BadWindow);
  4496.   if Hilite then
  4497.    begin
  4498.     BringToFront(whichWindow);
  4499.     ShowHide(whichWindow, TRUE);
  4500.    end;
  4501.   HiliteWindow(whichWindow, Hilite);
  4502. {If this window has a palette, bring it to the front as well.}
  4503.   case GetWClass(whichWindow) of
  4504. {You should modify the case selectors here to handle whatever kinds of 
  4505. windows with palettes your application supports.}
  4506.    wMiscWindowWithPalette: 
  4507.     begin
  4508.      if Hilite then
  4509.       begin
  4510.        AutoPositionPalettes(whichWindow);
  4511.        BringToFront(FindUniqueWindow(wMiscPalette));
  4512.       end;
  4513.      ShowHide(FindUniqueWindow(wMiscPalette), Hilite);
  4514.     end;
  4515.   end;
  4516.  end;
  4517.  
  4518. {Since we're using windows in a slightly unorthodox way, we can't rely on 
  4519. the Activate and Deactivate events}
  4520. {to do our work for us.  doSendPrivateActivateMessage is the routine to 
  4521. handle our equivalent of an Activate}
  4522. {event for the PrivateFrontWindow.  (Palettes can never be the 
  4523. PrivateFrontWindow, by definition.)}
  4524.  procedure doSendPrivateActivateMessage (whichWindow: WindowPtr);
  4525.  external;
  4526.  
  4527.  procedure privateActivate (whichWindow: WindowPtr);
  4528.  begin
  4529.   SetPrivateHilite(PrivateFrontWindow, FALSE);
  4530.   PrivateFrontWindow := whichWindow;
  4531.   SetPrivateHilite(PrivateFrontWindow, TRUE);
  4532. {Then send a message to update menus, etc.}
  4533.   doSendPrivateActivateMessage(PrivateFrontWindow);
  4534.  end;
  4535.  
  4536. end.
  4537.  
  4538.  
  4539.  
  4540.  
  4541. ---------------------------
  4542.  
  4543. >From grantd@dcs.gla.ac.uk (Dair Grant)
  4544. Subject: How does the Finder handle events?
  4545. Date: Wed, 9 Mar 1994 16:46:06 GMT
  4546. Organization: Glasgow University Computing Science Dept.
  4547.  
  4548.  
  4549. How does the Finder handle the high level Apple Events listed in its
  4550. 'fmnu' resources? I've sat in the event queue and watched the same events
  4551. arriving from other applications as expected, but the Finder doesn't
  4552. appear to send anything to itself for the same event (e.g., 'sdup').
  4553.  
  4554. I've also tried installing new handlers to override any original handlers,
  4555. but they're never actually called - in fact, they don't actually get to
  4556. override anything, as there don't seem to be any handlers installed which
  4557. they can override.
  4558.  
  4559. What mechanism does the Finder use for handling these AEs? How do things
  4560. like CopyDoubler intercept control? Any ideas?
  4561.  
  4562.  
  4563.  
  4564. -dair
  4565.  
  4566. +++++++++++++++++++++++++++
  4567.  
  4568. >From hubauer@telerama.lm.com (Bill Hubauer)
  4569. Date: 10 Mar 1994 08:24:35 -0500
  4570. Organization: Telerama Public Access Internet, Pittsburgh, PA
  4571.  
  4572. Dair Grant (grantd@dcs.gla.ac.uk) wrote:
  4573. :  
  4574. : How does the Finder handle the high level Apple Events listed in its
  4575. : 'fmnu' resources? I've sat in the event queue and watched the same events
  4576. : arriving from other applications as expected, but the Finder doesn't
  4577. : appear to send anything to itself for the same event (e.g., 'sdup').
  4578. :  
  4579. : I've also tried installing new handlers to override any original handlers,
  4580. : but they're never actually called - in fact, they don't actually get to
  4581. : override anything, as there don't seem to be any handlers installed which
  4582. : they can override.
  4583. :  
  4584. : What mechanism does the Finder use for handling these AEs? How do things
  4585. : like CopyDoubler intercept control? Any ideas?
  4586. :  
  4587. :  
  4588. :  
  4589. : -dair
  4590.  
  4591. The non-scriptable finder does not use the apple event manager at all.
  4592. It just uses highlevel events and parses them without the help of the
  4593. apple event manager.  This is why you can't patch in.
  4594.  
  4595. -- 
  4596. - -------------------------------------------
  4597. Bill Hubauer                          Hubauer@TeleRama.pgh.pa.us
  4598. AOL: MacBilly                         CIS: 76114,3012
  4599.  
  4600. +++++++++++++++++++++++++++
  4601.  
  4602. >From gurgle@netcom.com (Pete Gontier)
  4603. Date: Thu, 10 Mar 1994 17:45:01 GMT
  4604. Organization: cellular
  4605.  
  4606. hubauer@telerama.lm.com (Bill Hubauer) writes:
  4607.  
  4608. >Dair Grant (grantd@dcs.gla.ac.uk) wrote:
  4609.  
  4610. >: How does the Finder handle the high level Apple Events listed in its
  4611. >: 'fmnu' resources? I've sat in the event queue and watched the same
  4612. >: events arriving from other applications as expected, but the Finder
  4613. >: doesn't appear to send anything to itself for the same event (e.g.,
  4614. >: 'sdup').
  4615. >:
  4616. >: I've also tried installing new handlers to override any original
  4617. >: handlers, but they're never actually called - in fact, they don't
  4618. >: actually get to override anything, as there don't seem to be any
  4619. >: handlers installed which they can override.
  4620. >:
  4621. >: What mechanism does the Finder use for handling these AEs? How do
  4622. >: things like CopyDoubler intercept control? Any ideas?
  4623.  
  4624. >The non-scriptable finder does not use the apple event manager at all.
  4625. >It just uses highlevel events and parses them without the help of the
  4626. >apple event manager. This is why you can't patch in.
  4627.  
  4628. However, note that half of his investigations, he says, have been
  4629. with the event queue, not with the AppleEvent Manager. It would be
  4630. interesting to hear whether he is watching event records as they come
  4631. back from WNE or if he is waiting for Finder to call some other trap to
  4632. clue him in that there might be a high level event or AppleEvent being
  4633. handled. If the former, it sounds like Finder does not even defer its
  4634. event processing until the next iteration of the event loop. This would
  4635. not be surprising if Finder used AppleEvents, because the AE Manager
  4636. routes events sent to self directly to the handler. But we know Finder
  4637. is not using the AE Manager, so it might be that it sends high level
  4638. events to itself and somehow waits for the event loop to process them.
  4639. Then again, it might not. More information is in order. Oh, MacsBug...
  4640.  
  4641.     ATB A88F rA7^.w==34
  4642.  
  4643. ...which puts a break on PostHighLevelEvent, which is probably what
  4644. Finder would be using instead of AESend. Although it does get called
  4645. when Finder wants to open a document into a running app ('odoc' --
  4646. probably it's just the AE manager calling PostHighLevelEvent rather than
  4647. Finder), it doesn't get called when one makes a Finder menu selection
  4648. or drags an icon from one folder to another. However, doing little
  4649. investigations like this one is the very essence of this sort of hack.
  4650. Be persistent, and good luck.
  4651. -- 
  4652.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  4653.  
  4654. ---------------------------
  4655.  
  4656. >From dubois@uakari.primate.wisc.edu (Paul DuBois)
  4657. Subject: How to determine color of progress bar?
  4658. Date: 9 Mar 1994 23:05:40 -0600
  4659. Organization: Castra Parvulorum
  4660.  
  4661. When the Finder does a copy, it shows a progress bar.  How do
  4662. I tell what the background and foreground colors of the bar are?
  4663. -- 
  4664. Paul DuBois
  4665. dubois@primate.wisc.edu
  4666.  
  4667. +++++++++++++++++++++++++++
  4668.  
  4669. >From kenlong@netcom.com (Ken Long)
  4670. Date: Thu, 10 Mar 1994 08:47:42 GMT
  4671. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  4672.  
  4673. Do you want to tell what color they are, or make them be a certain color?
  4674.  
  4675. The gray is RGB 17476, and the lavender is R 52428, G 52428, B 65535.
  4676.  
  4677. Kinda hard to screen shot it while a dialog's cookin', huh.
  4678.  
  4679. The above numbers are from Joe Zobkiw's "Finder Prgress", which should 
  4680. also jive with Scott Knaster's "erasing your hard disk" SMP demo.
  4681.  
  4682. -Ken-
  4683.  
  4684. +++++++++++++++++++++++++++
  4685.  
  4686. >From kenlong@netcom.com (Ken Long)
  4687. Date: Thu, 10 Mar 1994 15:41:03 GMT
  4688. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  4689.  
  4690. That's "MPS" - not SMP.  ("club" finger, late night, craniaplegic, no 
  4691. glasses, keyboard worn out, etc.)
  4692.  
  4693. Mac Programming Secrets C source - dig?
  4694.  
  4695. -Ken-
  4696.  
  4697. +++++++++++++++++++++++++++
  4698.  
  4699. >From rmcassid@uci.edu (Robert Cassidy)
  4700. Date: Thu, 10 Mar 1994 10:24:22 -0700
  4701. Organization: TLG Project
  4702.  
  4703. In article <kenlongCMFxrI.Ep1@netcom.com>, kenlong@netcom.com (Ken Long)
  4704. wrote:
  4705.  
  4706. > Do you want to tell what color they are, or make them be a certain color?
  4707. > The gray is RGB 17476, and the lavender is R 52428, G 52428, B 65535.
  4708. > Kinda hard to screen shot it while a dialog's cookin', huh.
  4709. > The above numbers are from Joe Zobkiw's "Finder Prgress", which should 
  4710. > also jive with Scott Knaster's "erasing your hard disk" SMP demo.
  4711. > -Ken-
  4712.  
  4713. Does the progress bar vary it's colors according to the Color control panel
  4714. the way windows do? (I'd check, but I have a *%&$@# monochrome monitor)
  4715. I've only looked at windows and controls but these two have optional color
  4716. tables or system default color tables (based on Color control panel
  4717. settings) that contain the proper values. Look at Troy Gaul's Infinity
  4718. Windoid code. His code can show you what to do for black and white as well
  4719. as color - very helpful.
  4720.  
  4721. -- 
  4722. Robert Cassidy
  4723. TLG Project
  4724. UC Irvine
  4725.  
  4726. Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
  4727. decade...
  4728.  
  4729. +++++++++++++++++++++++++++
  4730.  
  4731. >From mgr@aggroup.aggroup.com (Mike Russell)
  4732. Date: Thu, 10 Mar 1994 12:40:57 -0800
  4733. Organization: the ag group, inc.
  4734.  
  4735. In article <2lm9r4INNj2v@uakari.primate.wisc.edu>,
  4736. dubois@uakari.primate.wisc.edu (Paul DuBois) wrote:
  4737.  
  4738. > When the Finder does a copy, it shows a progress bar.  How do
  4739. > I tell what the background and foreground colors of the bar are?
  4740.  
  4741. I use shades of the user's select color, as someone suggested long
  4742. ago in this news group.  That way you use a color that the user chose
  4743. and presumably likes.
  4744.  
  4745. +++++++++++++++++++++++++++
  4746.  
  4747. >From kenlong@netcom.com (Ken Long)
  4748. Date: Fri, 11 Mar 1994 01:25:27 GMT
  4749. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  4750.  
  4751. So how do you get the colors the user set with the Colors Control Panel?  
  4752. Greg's buttons taps those, too.
  4753.  
  4754. I wasn't aware the progress colors change along with it.  I'll have to 
  4755. see that for myself.  (Oh goody!  Something else to do on my Mac!)
  4756.  
  4757. -Ken-
  4758.  
  4759. +++++++++++++++++++++++++++
  4760.  
  4761. >From troy@i-link.com (Troy Gaul)
  4762. Date: 11 Mar 1994 00:35:51 -0600
  4763. Organization: I-Link, Ltd., Des Moines, IA, USA - 515/255-2754
  4764.  
  4765. In article <kenlongCMH7yH.n0o@netcom.com>, Ken Long <kenlong@netcom.com> wrote:
  4766. >So how do you get the colors the user set with the Colors Control Panel?  
  4767. >Greg's buttons taps those, too.
  4768.  
  4769. If you get the Infinity Windoid WDEF and look in the Windoid Util file,
  4770. there's a routine that gets a color from the window color table and sets
  4771. it as the fore (or back) color. For example, do a:
  4772.  
  4773.         WctbForeColor(nil, wTingeLight);
  4774.  
  4775. [The nil is the window parameter, you could pass in the WindowPtr, but
  4776. if you use nil, it'll just use the default color table from the System.]
  4777.  
  4778. With the standard window colors, this maps to the steel blue that we all
  4779. know and love.  With another tinge color, it maps to the appropriate
  4780. shade of that tinge.
  4781.  
  4782. >I wasn't aware the progress colors change along with it.  I'll have to 
  4783. >see that for myself.  (Oh goody!  Something else to do on my Mac!)
  4784.  
  4785. They don't.  I've always thought this was a little odd.  Actually, I've
  4786. tried doing a progress bar that uses the tinge color, but it doesn't
  4787. always look great (some of those tinge colors don't work well in that
  4788. large of an area).
  4789.  
  4790. _troy
  4791.  
  4792.  
  4793. -- 
  4794. //////// //////   Troy Gaul                            t-gaul@i-link.com   //
  4795.   //    //       I-Link, Ltd.                                             //
  4796.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)              //
  4797. //    ////// __________________________________________________________ //
  4798.  
  4799. +++++++++++++++++++++++++++
  4800.  
  4801. >From kenlong@netcom.com (Ken Long)
  4802. Date: Fri, 11 Mar 1994 09:06:30 GMT
  4803. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  4804.  
  4805. Thanks for that info, Troy.  I'll have to get that WDEF out and 
  4806. thoroughly read it, and read up on it!
  4807.  
  4808. -Ken-
  4809.  
  4810. "I love it when a plan comes together."
  4811.     George Peppard as "Hannibal Smith"
  4812.  
  4813. +++++++++++++++++++++++++++
  4814.  
  4815. >From jwbaxter@olympus.net (John W. Baxter)
  4816. Date: Fri, 11 Mar 1994 12:58:24 -0800
  4817. Organization: Internet for the Olympic Peninsula
  4818.  
  4819. In article <mgr-100394124057@mike.aggroup.com>, mgr@aggroup.aggroup.com
  4820. (Mike Russell) wrote:
  4821.  
  4822. > I use shades of the user's select color, as someone suggested long
  4823. > ago in this news group.  That way you use a color that the user chose
  4824. > and presumably likes.
  4825.  
  4826. As a user, I really wish you wouldn't (although for progress bars it's not
  4827. so bad).  AppleScript Script Editor has "forced" me to use a neutral grey
  4828. for my highlight color, because it wants to use a shade of my highlight for
  4829. the frame of its script editing window (monitor in 16-color mode).  With a
  4830. highly visible highlight color, the result is bizarre.
  4831.  
  4832. -- 
  4833. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  4834.    jwbaxter@pt.olympus.net
  4835.  
  4836. +++++++++++++++++++++++++++
  4837.  
  4838. >From kenh@world.std.com (Ken Hancock)
  4839. Date: Sat, 12 Mar 1994 01:11:19 GMT
  4840. Organization: Isle Systems - Nashua, NH
  4841.  
  4842. In article <2lp3g7$l1p@ilink1.i-link.com>, Troy Gaul <troy@i-link.com> wrote:
  4843. >In article <kenlongCMH7yH.n0o@netcom.com>, Ken Long <kenlong@netcom.com> wrote:
  4844. >>I wasn't aware the progress colors change along with it.  I'll have to 
  4845. >>see that for myself.  (Oh goody!  Something else to do on my Mac!)
  4846. >
  4847. >They don't.  I've always thought this was a little odd.  Actually, I've
  4848. >tried doing a progress bar that uses the tinge color, but it doesn't
  4849. >always look great (some of those tinge colors don't work well in that
  4850. >large of an area).
  4851.  
  4852. This is one of the things which makes me think that the window color
  4853. control panel was a (good) hack by one of the engineeers who couldn't
  4854. stand the "standard" purple.  Personally, I've always done my
  4855. progress bars using wTingeLight as Apple should have, IMHO.
  4856. (It loes look silly having everything else in the window gold or green
  4857. but still have that $#*& progress bar be purple)
  4858.  
  4859. Ken
  4860.  
  4861.  
  4862. -- 
  4863. Ken Hancock             | INTERNET: kenh@vgi.com 
  4864. Isle Systems            | Compuserve: >INTERNET: kenh@vgi.com
  4865. Macintosh Consulting    | AOL: KHancock 
  4866.                         | Disclaimer: My opinions are mine,
  4867.  
  4868. +++++++++++++++++++++++++++
  4869.  
  4870. >From markhanrek@aol.com (MarkHanrek)
  4871. Date: 12 Mar 1994 04:54:01 -0500
  4872. Organization: America Online, Inc. (1-800-827-6364)
  4873.  
  4874. Do a cmd-shift-3 to take a snapshot of the screen while the progress dialog is
  4875. up, then use the eyedropper tool of any color graphics editing / paint program
  4876. to determine the RGB value or the indexed color value.
  4877.  
  4878. Mark Hanrek
  4879.  
  4880.  
  4881. +++++++++++++++++++++++++++
  4882.  
  4883. >From kenlong@netcom.com (Ken Long)
  4884. Date: Sat, 12 Mar 1994 19:14:30 GMT
  4885. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  4886.  
  4887. I don't know if it happens in every instance, but, usually, when there's 
  4888. some operation going on and you try to do a screen shot, the command to 
  4889. do the screen shot goes on the "waiting list" and is carried out after 
  4890. the current operation is complete.
  4891.  
  4892. Sometimes you can sneak a screenshot in if the operation is operating in 
  4893. a loop and checks for events (like the ones that look for keyDowns like 
  4894. Command-. etc.).
  4895.  
  4896. But those colors are pretty easy to spot in a system color palette, in 
  4897. ResEdit or a color paint program - especially after seeing them several 
  4898. times a day, 7 days a week, for 2 (?) years.
  4899.  
  4900. -Ken-
  4901.  
  4902. +++++++++++++++++++++++++++
  4903.  
  4904. >From D.A.G.Gillies@bradford.ac.uk (David Gillies)
  4905. Date: Mon, 14 Mar 1994 17:57:47 GMT
  4906. Organization: Unseen University, Ankh-Morpork
  4907.  
  4908. In article <rmcassid-100394102422@rmcassidy.tlg.uci.edu> rmcassid@uci.edu (Robert Cassidy) writes:
  4909. >In article <kenlongCMFxrI.Ep1@netcom.com>, kenlong@netcom.com (Ken Long)
  4910. >wrote:
  4911. >
  4912. >> Do you want to tell what color they are, or make them be a certain color?
  4913. >> 
  4914. >> The gray is RGB 17476, and the lavender is R 52428, G 52428, B 65535.
  4915. >> 
  4916. >> Kinda hard to screen shot it while a dialog's cookin', huh.
  4917. >> 
  4918. >> The above numbers are from Joe Zobkiw's "Finder Prgress", which should 
  4919. >> also jive with Scott Knaster's "erasing your hard disk" SMP demo.
  4920. >> 
  4921. >> -Ken-
  4922. >
  4923. >Does the progress bar vary it's colors according to the Color control panel
  4924. >the way windows do? (I'd check, but I have a *%&$@# monochrome monitor)
  4925. >I've only looked at windows and controls but these two have optional color
  4926. >tables or system default color tables (based on Color control panel
  4927. >settings) that contain the proper values. Look at Troy Gaul's Infinity
  4928. >Windoid code. His code can show you what to do for black and white as well
  4929. >as color - very helpful.
  4930.  
  4931.  
  4932. If it's any help, the lilac colour is no. 42 in the standard system palette.
  4933. I implement the progress bar by just having the system palette in my
  4934. application and calling PmForeColor(42). Maybe not very elegant, but hey, it
  4935. works.
  4936.  
  4937. ______________________________________________________________________
  4938. David A. G. Gillies                     (D.A.G.Gillies@bradford.ac.uk)
  4939. (c) 1994 Wittgenstein and The Furniture Depository of The Living Dead
  4940.  
  4941. A little learning is a dangerous thing - but not half as dangerous as a
  4942. lot of ignorance.
  4943.  
  4944. - ---------------------REPLIES VIA EMAIL PLEASE-----------------------
  4945. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  4946.  
  4947. +++++++++++++++++++++++++++
  4948.  
  4949. >From walrathw@rferl.org (WalrathW)
  4950. Date: 14 Mar 94 15:31:56 -0500
  4951. Organization: RFE/RL Inc.
  4952.  
  4953. In article <2ls3fp$qta@search01.news.aol.com>
  4954. markhanrek@aol.com (MarkHanrek) writes:
  4955.  
  4956. > Do a cmd-shift-3 to take a snapshot of the screen while the progress dialog is
  4957. > up, then use the eyedropper tool of any color graphics editing / paint program
  4958. > to determine the RGB value or the indexed color value.
  4959. > Mark Hanrek
  4960.  
  4961. I should also point out a very useful set of FKEYs called Jon's FKEYs
  4962. which I use all the time. There is one which lets you get the color of
  4963. any pixel on the screen (in RGB, HSV, or CMY), and another which lets
  4964. you drag out a rect of marching ants and gives you the coordinates. I
  4965. use them all the time for determining what the cool colors other
  4966. developers are using in their hacks are. They're available at the usual
  4967. Mac archive sites.
  4968.  
  4969.  
  4970. ________oOo________ 
  4971.  Wayne Walrath    
  4972.  RFE/RL Inc.
  4973.  walrathW@rferl.org
  4974.  
  4975. +++++++++++++++++++++++++++
  4976.  
  4977. >From zobkiw@datawatch.com (joe zobkiw)
  4978. Date: Tue, 15 Mar 1994 12:29:12 GMT
  4979. Organization: Datawatch Corporation
  4980.  
  4981. In article <1994Mar14.153157.371@dcvaxb.rferl.org>, walrathw@rferl.org
  4982. (WalrathW) wrote:
  4983.  
  4984. Forget it...use this routine...this will return the light and dark tinges
  4985. currently being used by the WDEF/CDEF in System 7 to draw things like
  4986. scroll bars and window borders, etc. You can then use these colors to draw
  4987. the foreground and background of your progress bar. This way, you will
  4988. always match what the user has selected in the Color control panel.
  4989.  
  4990. And NO you shouldn't release the resource. Try it and you'll see why :)
  4991.  
  4992. /*******************************************************************************
  4993.  
  4994.     GetWindowTinges
  4995.  
  4996.     Should have color quickdraw for this routine to be called
  4997. *******************************************************************************/
  4998.  
  4999. void GetWindowTinges(RGBColor *lightTinge, RGBColor *darkTinge)
  5000. {
  5001.     CTabHandle    windowCTable;
  5002.     
  5003.     lightTinge->red = lightTinge->green = lightTinge->blue = 0xffff;
  5004.     darkTinge->red = darkTinge->green = darkTinge->blue = 0x0000;
  5005.     
  5006.     if ((windowCTable = (CTabHandle)GetResource('wctb', 0)) != nil) {
  5007.         *lightTinge = (**windowCTable).ctTable[11].rgb;
  5008.         *darkTinge = (**windowCTable).ctTable[12].rgb;
  5009.     }
  5010.     
  5011.     /* case for black and white window defs under system 7, both return black!
  5012. */
  5013.     if ((lightTinge->red == 0x0000) && (lightTinge->green == 0x0000) &&
  5014. (lightTinge->blue == 0x0000))
  5015.         lightTinge->red = lightTinge->green = lightTinge->blue = 0xffff;
  5016.  
  5017. }
  5018.  
  5019. ___________________________________________________________
  5020. _/_/_/_/   Joe Zobkiw                                   ,,,
  5021.     _/     Senior Software Engineer                     - -
  5022.   _/       Datawatch Corporation                         L
  5023. _/_/_/_/   zobkiw@datawatch.com                          -
  5024.  
  5025. +++++++++++++++++++++++++++
  5026.  
  5027. >From KLUEV@jonathan.srcc.msu.su
  5028. Date: Wed, 16 Mar 1994 21:06:43 +0300
  5029. Organization: (none)
  5030.  
  5031. In article <zobkiw-150394072912@zobkiw.datawatch.com>
  5032. zobkiw@datawatch.com (joe zobkiw) writes:
  5033. >In article <1994Mar14.153157.371@dcvaxb.rferl.org>, walrathw@rferl.org
  5034. >(WalrathW) wrote:
  5035. >
  5036. >Forget it...use this routine...this will return the light and dark tinges
  5037. >currently being used by the WDEF/CDEF in System 7 to draw things like
  5038. >scroll bars and window borders, etc. You can then use these colors to draw
  5039. >the foreground and background of your progress bar. This way, you will
  5040. >always match what the user has selected in the Color control panel.
  5041. >
  5042. >And NO you shouldn't release the resource. Try it and you'll see why :)
  5043. >
  5044. ... Code deleted ...
  5045. >        if ((windowCTable = (CTabHandle)GetResource('wctb', 0)) != nil) {
  5046. >                *lightTinge = (**windowCTable).ctTable[11].rgb;
  5047. >                *darkTinge = (**windowCTable).ctTable[12].rgb;
  5048. ...
  5049.  
  5050. It's better to use GetAuxWin procedure. This way you will take into
  5051. account custom 'wctb's.
  5052.  
  5053. Michael Kluev.
  5054.  
  5055. +++++++++++++++++++++++++++
  5056.  
  5057. >From rollin@newton.apple.com (Keith Rollin)
  5058. Date: Sun, 13 Mar 1994 01:32:55 GMT
  5059. Organization: Apple Computer, Inc.
  5060.  
  5061. In article <2ls3fp$qta@search01.news.aol.com>, markhanrek@aol.com
  5062. (MarkHanrek) wrote:
  5063.  
  5064. > Do a cmd-shift-3 to take a snapshot of the screen while the progress dialog is
  5065. > up, then use the eyedropper tool of any color graphics editing / paint program
  5066. > to determine the RGB value or the indexed color value.
  5067.  
  5068. A neat idea, but not the best way to go. The color specified by the program
  5069. drawing the progress bar (e.g., the Finder) is not necessarily the one that
  5070. appears on the screen. Instead, the RGB color specified is mapped to the
  5071. closest available color in the screen device's color table. To look at an
  5072. extreme example, if the screen is in B&W mode, a nice purple will get
  5073. mapped to black. Even on a 256 color device, the color specified will
  5074. almost always be different than that displayed.
  5075.  
  5076. When I was working on "Macintosh Programming Secrets", I wanted to get the
  5077. *exact* colors that the Finder was using. To do this, I set breakpoints on
  5078. a few of QuickDraw's calls (like PaintRect and FillCRect). I can't remember
  5079. exactly what call the Finder was using, but when I broke into the debugger,
  5080. I was able to either look at the color being passed into the call, or the
  5081. RGBForeColor in the current CGrafPort.
  5082.  
  5083. - --------------------------------------------------------------------------
  5084. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team
  5085. Newton
  5086.  
  5087. +++++++++++++++++++++++++++
  5088.  
  5089. >From melissa@i-link.com (Melissa Gaul)
  5090. Date: Wed, 16 Mar 1994 18:41:48 -0600
  5091. Organization: I-Link, Ltd.
  5092.  
  5093. In article <862D4F21C8@VADIK.srcc.msu.su>, KLUEV@jonathan.srcc.msu.su
  5094. wrote:
  5095.  
  5096. > In article <zobkiw-150394072912@zobkiw.datawatch.com>
  5097. > zobkiw@datawatch.com (joe zobkiw) writes:
  5098. > >In article <1994Mar14.153157.371@dcvaxb.rferl.org>, walrathw@rferl.org
  5099. > >(WalrathW) wrote:
  5100. > >
  5101. > >Forget it...use this routine...this will return the light and dark tinges
  5102. > >currently being used by the WDEF/CDEF in System 7 to draw things like
  5103. > >scroll bars and window borders, etc. You can then use these colors to draw
  5104. > >the foreground and background of your progress bar. This way, you will
  5105. > >always match what the user has selected in the Color control panel.
  5106. > >
  5107. > >And NO you shouldn't release the resource. Try it and you'll see why :)
  5108. > >
  5109. > ... Code deleted ...
  5110. > >        if ((windowCTable = (CTabHandle)GetResource('wctb', 0)) != nil) {
  5111. > >                *lightTinge = (**windowCTable).ctTable[11].rgb;
  5112. > >                *darkTinge = (**windowCTable).ctTable[12].rgb;
  5113. > ...
  5114. > It's better to use GetAuxWin procedure. This way you will take into
  5115. > account custom 'wctb's.
  5116.  
  5117. If you do this, you should also be prepared in case the window's color
  5118. table (from GetAuxWin) isn't long enough to hold the tinge colors you're
  5119. looking for. Then, you could try GetAuxWin(nil) and try there, but this
  5120. might still not have enough, so you should have some built-in defaults. 
  5121.  
  5122. (This all assumes you want to handle all cases. If you control the windows
  5123. in your application and know this isn't needed, you might be able to avoid
  5124. it.)
  5125.  
  5126. _troy
  5127. ////////_//////___Troy Gaul_________________________t-gaul@i-link.com___//
  5128.   //    //       I-Link, Ltd.                                          //
  5129.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
  5130. //____//////_________________________________________________________//
  5131.  
  5132. +++++++++++++++++++++++++++
  5133.  
  5134. >From giles@med.cornell.edu (Aaron Giles)
  5135. Date: Wed, 16 Mar 1994 22:12:52 -0500
  5136. Organization: Cornell University Medical College
  5137.  
  5138. In article <rollin-120394173255@rollin-keith.apple.com>,
  5139. rollin@newton.apple.com (Keith Rollin) wrote:
  5140.  
  5141. > In article <2ls3fp$qta@search01.news.aol.com>, markhanrek@aol.com
  5142. > (MarkHanrek) wrote:
  5143. >> Do a cmd-shift-3 to take a snapshot of the screen while the progress dialog is
  5144. >> up, then use the eyedropper tool of any color graphics editing / paint program
  5145. >> to determine the RGB value or the indexed color value.
  5146. > A neat idea, but not the best way to go. The color specified by the program
  5147. > drawing the progress bar (e.g., the Finder) is not necessarily the one that
  5148. > appears on the screen. Instead, the RGB color specified is mapped to the
  5149. > closest available color in the screen device's color table.
  5150.  
  5151. Of course, if you do this on a 24-bit color screen, you don't need to
  5152. worry. :-)  If you want your progress bars to look like the Finder's, try:
  5153.  
  5154.     static RGBColor gBarBackground = { 0xcccc, 0xcccc, 0xffff };
  5155.     static RGBColor gBarForeground = { 0x6666, 0x6666, 0x6666 };
  5156.  
  5157. Assuming that "background" refers to the steel blue, and "foreground"
  5158. refers to the gray.
  5159.  
  5160. Aaron
  5161. -- 
  5162. Aaron Giles
  5163. Macintosh & Newton Developer
  5164. Cornell University Medical College
  5165. giles@med.cornell.edu
  5166.  
  5167. +++++++++++++++++++++++++++
  5168.  
  5169. >From troy@i-link.com (Troy Gaul)
  5170. Date: Thu, 17 Mar 1994 00:02:56 -0600
  5171. Organization: I-Link, Ltd.
  5172.  
  5173. >In article <melissa-160394184148@ts1-3.i-link.com>, melissa@i-link.com 
  5174. >(Melissa Gaul) wrote:
  5175.  
  5176. Oops, that was supposed to be me, not my wife. :(
  5177.  
  5178. Just goes to show how a mechanism for having different preferences files
  5179. for two people who use the same machine can be important, I guess...
  5180.  
  5181. _troy
  5182. ////////_//////___Troy Gaul_________________________t-gaul@i-link.com___//
  5183.   //    //       I-Link, Ltd.                                          //
  5184.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
  5185. //____//////_________________________________________________________//
  5186.  
  5187. +++++++++++++++++++++++++++
  5188.  
  5189. >From arentz@batcave.knoware.nl (Stefan Arentz)
  5190. Date: Thu, 17 Mar 1994 17:15:57 GMT
  5191. Organization: Knoware
  5192.  
  5193. In article <rollin-120394173255@rollin-keith.apple.com>,
  5194. rollin@newton.apple.com (Keith Rollin) wrote:
  5195.  
  5196. > When I was working on "Macintosh Programming Secrets", I wanted to get the
  5197. > *exact* colors that the Finder was using. To do this, I set breakpoints on
  5198. > a few of QuickDraw's calls (like PaintRect and FillCRect). I can't remember
  5199. > exactly what call the Finder was using, but when I broke into the debugger,
  5200. > I was able to either look at the color being passed into the call, or the
  5201. > RGBForeColor in the current CGrafPort.
  5202.  
  5203. RGBColor    CProgressIndicator::mBlack     = { 0x0000, 0x0000, 0x0000 };
  5204. RGBColor    CProgressIndicator::mWhite     = { 0xFFFF, 0xFFFF, 0xFFFF };
  5205. RGBColor    CProgressIndicator::mDarkGrey  = { 0x4000, 0x4000, 0x4000 };
  5206. RGBColor    CProgressIndicator::mSteelBlue    = { 0xCCCC, 0xCCCC, 0xFFFF };
  5207.  
  5208. Black is black, White is white, SteelBlue is the background color of the
  5209. indicator, and DarkGray is the color of the moving bar...
  5210.  
  5211. Great Book Keith! ;-)
  5212.  
  5213. > ----------------------------------------------------------------------------
  5214. > Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
  5215.  
  5216. Er, Team Newton? Does this mean we can expect a 'Newton Programming
  5217. Secrets'?
  5218.  
  5219. -- Stefan
  5220.  
  5221. - -----------------------------------------------------------------------
  5222. Stefan Arentz    -- Lunatech Software Development --    arentz@knoware.nl
  5223.  
  5224. +++++++++++++++++++++++++++
  5225.  
  5226. >From mshields%peruvian.cs.utah.edu@cs.utah.edu (Michael S Shields)
  5227. Date: 17 Mar 94 16:25:05 MST
  5228. Organization: University of Utah Computer Science
  5229.  
  5230.  
  5231. Um,
  5232.  
  5233. I just did a little test and I found that the progress bar in a finder copy
  5234. doesn't depend on the window cor.  I usually have my windws at the "Standard"
  5235. color, so I switched it to red and the progress bar was still in the dark grey/
  5236. purplish color combo. So, I think that putting up a progress bar in the window
  5237. colors might be unnerving to a user if you are trying to mimic the Finder.
  5238. Also, it's work you could eliminate to spend more time on other things.
  5239.  
  5240. Mike
  5241. mshields@peruvian.cs.utah.edu
  5242. mshields@dayna.com
  5243.  
  5244.  
  5245.  
  5246. ---------------------------
  5247.  
  5248. >From peloy@ccxbbs.uunet.ve
  5249. Subject: How to draw inits icons?
  5250. Date: 2 Mar 1994 07:35:11 -0600
  5251. Organization: Caracas Computer Exchange BBS
  5252.  
  5253. To: comp-sys-mac-programmer@cs.utexas.edu
  5254.  
  5255. Hello there.
  5256.  
  5257. I've looking so far to find how to draw my INIT's icon on the bottom of the
  5258. screen at boot time. I haven't found anything in Inside Macintosh or in the
  5259. Technical Notes.
  5260.  
  5261. I would like to know how can I do this. I could borrow the code needed to draw
  5262. the icon from any INIT but I would like to understand how it works. When doing
  5263. "reverse engineering" on the code to draw INIT's icons, I've found some low
  5264. memory variables that are not documented.
  5265.  
  5266. It would be very fine if you can send me source code to do this or you can
  5267. explain me how to do my own code.
  5268.  
  5269. I don't have direct access to c.s.m.p. so please send your help to my
  5270. electronic address (peloy@ccxbbs.uunet.ve).
  5271.  
  5272. Thans a lot in advance,
  5273. Eloy A. Paris <peloy@ccxbbs.uunet.ve>
  5274.  
  5275.  
  5276.  -> Alice4Mac 2.2.2E QWK Ser#127-1073 
  5277.  
  5278. +++++++++++++++++++++++++++
  5279.  
  5280. >From kenlong@netcom.com (Ken Long)
  5281. Date: Wed, 2 Mar 1994 16:58:26 GMT
  5282. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  5283.  
  5284. There's a couple files you can get.  Connect to:
  5285.  
  5286. ftp bigbird.csd.scarolina.edu
  5287.  
  5288. and in the pub/mac directory is Jim Walker's "ShowIcon7" - a C project 
  5289. and info on doing that.
  5290.  
  5291. Then, in alt.sources.mac is a file I got off AOL that is a C project for 
  5292. generic control panels and INITs which use "ShowINIT.c" to show it.  I 
  5293. tried the example CP in this file and it did, indeed, show its icon on 
  5294. startup.  The file is probably on sumex, as well.
  5295.  
  5296. -Ken-
  5297.  
  5298. ---------------------------
  5299.  
  5300. >From dat91jre@ludat.lth.se (Regmyr Jonas)
  5301. Subject: How to tell a Mac from a Mac?
  5302. Date: 7 Mar 1994 08:49:33 GMT
  5303. Organization: Lund Institute of Technology, Sweden
  5304.  
  5305. Hi!
  5306.  
  5307. Is there a way to tell one Mac from anotherone or, is there a way
  5308. for a program to tell if it has been moved from one machine to
  5309. anotherone, possible the same type (from, say, one Classic to another)?
  5310. If so, how do I do this?
  5311.  
  5312. I've thought about some ways to achive this:
  5313. If there is a way to get the serial # of the machine the problem
  5314.     is solved (probably won't work).
  5315. One could use the name of the boot volume but, what if the user
  5316.     change it -> program will get confused (not so nice approach).
  5317. If there is a way to write to ROM there is a way to check the
  5318.     appearance of some word, bit or whatever and by that know if
  5319.     I've (the program) been here before (can one do this?).
  5320.  
  5321. For me, this problem is yet to be solved.
  5322. Please help me.
  5323.  
  5324. Thanx...
  5325.  
  5326.                     /Jonas...
  5327.  
  5328.  
  5329. -- 
  5330. Mail: Karl Jonas Regmyr   Carl Hillsgatan 9   S-217 56 Malmoe Sweden
  5331. Phone: +46 (0)40 91 42 41               Email: dat91jre@ludat.lth.se
  5332.  
  5333. +++++++++++++++++++++++++++
  5334.  
  5335. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  5336. Date: 7 Mar 1994 11:02:09 GMT
  5337. Organization: Royal Institute of Technology, Stockholm, Sweden
  5338.  
  5339. In <2lepqt$1g3@nic.lth.se> dat91jre@ludat.lth.se (Regmyr Jonas) writes:
  5340.  
  5341. >Is there a way to tell one Mac from anotherone or, is there a way
  5342. >for a program to tell if it has been moved from one machine to
  5343. >anotherone, possible the same type (from, say, one Classic to another)?
  5344.  
  5345. Yes; write your program to require an ADB dongle; thus if your
  5346. user moves the application but not the dongle (hardware key)
  5347. your app will notice it has been moved.
  5348.  
  5349. Copy protection in evil.
  5350.  
  5351. >If there is a way to get the serial # of the machine the problem
  5352.  
  5353. Nope.
  5354.  
  5355. >One could use the name of the boot volume but, what if the user
  5356. >    change it -> program will get confused (not so nice approach).
  5357.  
  5358. Very bad; users switch between systems daily for things like
  5359. System 6 or Kanji or whatever.
  5360.  
  5361. >If there is a way to write to ROM there is a way to check the
  5362. >    appearance of some word, bit or whatever and by that know if
  5363. >    I've (the program) been here before (can one do this?).
  5364.  
  5365. ROM == Read-Only Memory == not-writable.
  5366.  
  5367. The simplest thing you can do is to check if your preferences
  5368. file is there in the preferences folder; if it's not, it's
  5369. probably a new installation (or the user installed a new system
  5370. or restored a backup, or switched systems or whatever)
  5371.  
  5372. -- 
  5373.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  5374.  
  5375.    This article printed on 100% recycled electrons.
  5376.  
  5377. +++++++++++++++++++++++++++
  5378.  
  5379. >From Matt Slot <fprefect@engin.umich.edu>
  5380. Date: 7 Mar 1994 11:45:09 GMT
  5381. Organization: University of Michigan
  5382.  
  5383.  Regmyr Jonas, dat91jre@ludat.lth.se writes:
  5384.  
  5385. >Is there a way to tell one Mac from another one or, is there a way
  5386. >for a program to tell if it has been moved from one machine to
  5387. >anotherone, possible the same type (from, say, one Classic to another)?
  5388. >If so, how do I do this?
  5389. - -----------
  5390. First a note: dont make self-modifying apps! Your app should not store
  5391. machine specific information within itself; if you save a preference
  5392. do it to a preferences file. 
  5393.  
  5394. OK, off the podium. If you still need to identify a Mac from another,
  5395. use the Volume Creation date for VRefNum = -1. This is the long date
  5396. to the second of the initialization of that HD. For a 1 in 4 billion
  5397. chance of duplication, this works rather well. If the user *does*
  5398. reformat the boot disk, it will probably be a full reinstall and for
  5399. all intents a "new" machine.
  5400.  
  5401. Matt
  5402.  
  5403. +++++++++++++++++++++++++++
  5404.  
  5405. >From u9119523@sys.uea.ac.uk (Graham Cox)
  5406. Date: Mon, 7 Mar 1994 11:32:44 GMT
  5407. Organization: School of Information Systems, UEA, Norwich
  5408.  
  5409. In article <2lf1jh$rk2@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte)
  5410. wrote:
  5411.  
  5412. > In <2lepqt$1g3@nic.lth.se> dat91jre@ludat.lth.se (Regmyr Jonas) writes:
  5413. > >Is there a way to tell one Mac from anotherone or, is there a way
  5414. > >for a program to tell if it has been moved from one machine to
  5415. > >anotherone, possible the same type (from, say, one Classic to another)?
  5416.  
  5417. Here's a simple way. Get the Date/Time of initialization of the startup
  5418. disk. As this is accurate to the second, the chance of two Macs having
  5419. their hard disks initialised at the same time is very small.
  5420.  
  5421. You can store this value in your app's preferences, and compare it with the
  5422. current disk at startup. If different, you can ask the user to enter a
  5423. validation code. If correct, you can then update the disk "ID" so the user
  5424. doesn't get bothered again, unless the program is copied to another
  5425. machine. If you add some kind of encryption to the stored values, the
  5426. likelihood of someone being able to hack the values is virtually
  5427. non-existent. I used this method on a commercial app and it works a treat.
  5428. It's also one of the few copy-protection methods thats absolutely
  5429. compatible with the system and unlikely to fail in future releases.
  5430.  
  5431.  
  5432. - ------------------------------------------------------------------------
  5433. Love & BSWK, Graham
  5434.  
  5435. -Everyone is entitled to their opinion, no matter how wrong they may be...
  5436. - ------------------------------------------------------------------------
  5437.  
  5438. +++++++++++++++++++++++++++
  5439.  
  5440. >From ajr3@quads.uchicago.edu (Alain Roy)
  5441. Date: Mon, 7 Mar 1994 15:00:36 GMT
  5442. Organization: University of Chicago
  5443.  
  5444. In article <u9119523-070394123244@graphics1.sys.uea.ac.uk> u9119523@sys.uea.ac.uk (Graham Cox) writes:
  5445. >
  5446. >Here's a simple way. Get the Date/Time of initialization of the startup
  5447. >disk. As this is accurate to the second, the chance of two Macs having
  5448. >their hard disks initialised at the same time is very small.
  5449.  
  5450. works unless you're like me: i have 2 hard drives. if every time i switched,
  5451. i had the copy protection of a program fire up, i'd be really upset.
  5452.  
  5453. -alain
  5454.  
  5455. +++++++++++++++++++++++++++
  5456.  
  5457. >From time@garnet.msen.com (Tim Endres)
  5458. Date: 7 Mar 1994 19:22:52 GMT
  5459. Organization: Msen, Inc. -- Ann Arbor, MI (account info: +1 313 998-4562)
  5460.  
  5461. Matt Slot (fprefect@engin.umich.edu) wrote:
  5462. :  Regmyr Jonas, dat91jre@ludat.lth.se writes:
  5463. :  
  5464. : >Is there a way to tell one Mac from another one or, is there a way
  5465. : >for a program to tell if it has been moved from one machine to
  5466. : >anotherone, possible the same type (from, say, one Classic to another)?
  5467. : >If so, how do I do this?
  5468. : -------------
  5469. : First a note: dont make self-modifying apps! Your app should not store
  5470. : machine specific information within itself; if you save a preference
  5471. : do it to a preferences file. 
  5472.  
  5473. Unless you need a self-modifying app, such as TransIt.
  5474.  
  5475. : OK, off the podium. If you still need to identify a Mac from another,
  5476. : use the Volume Creation date for VRefNum = -1. This is the long date
  5477. : to the second of the initialization of that HD. For a 1 in 4 billion
  5478.  
  5479. Except that most times are in the range from 1984 to 1994, as
  5480. opposed to 1904 to 1994. Thus, closer to 478 Million. Still reasonable.
  5481.  
  5482. : chance of duplication, this works rather well. If the user *does*
  5483. : reformat the boot disk, it will probably be a full reinstall and for
  5484. : all intents a "new" machine.
  5485.  
  5486. Or, as pointed out, the user boots from more than one
  5487. volume. In this case, you need to keep a "list" of
  5488. drives, which may not be what you want.
  5489.  
  5490. +++++++++++++++++++++++++++
  5491.  
  5492. >From gregor@nrlfs1.nrl.navy.mil (joe gregor)
  5493. Date: Mon, 7 Mar 1994 19:45:14 GMT
  5494. Organization: NRL
  5495.  
  5496. In Article <2lf445$5qd@lastactionhero.rs.itd.umich.edu>, Matt Slot
  5497. <fprefect@engin.umich.edu> wrote:
  5498.  
  5499. >OK, off the podium. If you still need to identify a Mac from another,
  5500. >use the Volume Creation date for VRefNum = -1. This is the long date
  5501. >to the second of the initialization of that HD. For a 1 in 4 billion
  5502. >chance of duplication, this works rather well. If the user *does*
  5503. >reformat the boot disk, it will probably be a full reinstall and for
  5504. >all intents a "new" machine.
  5505. >
  5506.     Never had to replace a hard disk before, huh.
  5507.  
  5508.             -- Joe
  5509.  
  5510. +++++++++++++++++++++++++++
  5511.  
  5512. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  5513. Date: Mon, 7 Mar 94 13:52:36 PST
  5514. Organization: Peirce Software, Inc.
  5515.  
  5516.  
  5517. In article <u9119523-070394123244@graphics1.sys.uea.ac.uk> (comp.sys.mac.programmer), u9119523@sys.uea.ac.uk (Graham Cox) writes:
  5518. > Here's a simple way. Get the Date/Time of initialization of the startup
  5519. > disk. As this is accurate to the second, the chance of two Macs having
  5520. > their hard disks initialised at the same time is very small.
  5521. > You can store this value in your app's preferences, and compare it with the
  5522. > current disk at startup. If different, you can ask the user to enter a
  5523. > validation code. If correct, you can then update the disk "ID" so the user
  5524. > doesn't get bothered again, unless the program is copied to another
  5525. > machine. If you add some kind of encryption to the stored values, the
  5526. > likelihood of someone being able to hack the values is virtually
  5527. > non-existent. I used this method on a commercial app and it works a treat.
  5528. > It's also one of the few copy-protection methods thats absolutely
  5529. > compatible with the system and unlikely to fail in future releases.
  5530.  
  5531. How do people feel about this technique.  Are there any obvious drawbacks?
  5532.  
  5533. It does mean you need to "install" the software on each new system
  5534. disk, any objections to this?
  5535.  
  5536.  
  5537. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  5538. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  5539. --                       -- San Jose, California USA 95117
  5540. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  5541. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  5542.  
  5543. +++++++++++++++++++++++++++
  5544.  
  5545. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  5546. Date: 8 Mar 1994 13:04:08 +0800
  5547. Organization: NCRPDA, Curtin University
  5548.  
  5549. time@garnet.msen.com (Tim Endres) writes:
  5550.  
  5551. >: First a note: dont make self-modifying apps! Your app should not store
  5552. >: machine specific information within itself; if you save a preference
  5553. >: do it to a preferences file. 
  5554.  
  5555. >Unless you need a self-modifying app, such as TransIt.
  5556.  
  5557. Besides, it's perfectly reasonable to modify yourself during instalation.
  5558. But it would definiitely be bad later on when the admin has writeprotected
  5559. the directory (and it's not much use on CDROMs either, etc).
  5560.  
  5561. >Or, as pointed out, the user boots from more than one
  5562. >volume. In this case, you need to keep a "list" of
  5563. >drives, which may not be what you want.
  5564.  
  5565. That's not really needed - if you boot from a seperate disk, then you'll
  5566. have a seperate prefs file, so you'll have to enter the serial number
  5567. once per system folder, thats not particularly unreasonable (and I hate
  5568. copy protection!).
  5569.  
  5570. The main draw back of this scheme is that it's a royal pain in the ass
  5571. for network mutli-user licenses.  I think you can guess how happy I'd be
  5572. to buy a twenty user license and then have the fun of going around
  5573. typing serial numbers into every damn machine - and since this is such
  5574. a pain, I'll probably not recomend your software as the one to buy...
  5575.    Peter.
  5576. -- 
  5577. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  5578.  
  5579. +++++++++++++++++++++++++++
  5580.  
  5581. >From ivanski@world.std.com (Ivan M CaveroBelaunde)
  5582. Date: Tue, 8 Mar 1994 16:30:43 GMT
  5583. Organization: The World Public Access UNIX, Brookline, MA
  5584.  
  5585. peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  5586. >In article <u9119523-070394123244@graphics1.sys.uea.ac.uk> (comp.sys.mac.programmer), u9119523@sys.uea.ac.uk (Graham Cox) writes:
  5587. >> Here's a simple way. Get the Date/Time of initialization of the startup
  5588. >> disk. As this is accurate to the second, the chance of two Macs having
  5589. >> their hard disks initialised at the same time is very small.
  5590. >> 
  5591. >> You can store this value in your app's preferences, and compare it with the
  5592. >> current disk at startup. If different, you can ask the user to enter a
  5593. >> validation code. If correct, you can then update the disk "ID" so the user
  5594. >> doesn't get bothered again, unless the program is copied to another
  5595. >> machine. If you add some kind of encryption to the stored values, the
  5596. >> likelihood of someone being able to hack the values is virtually
  5597. >> non-existent. I used this method on a commercial app and it works a treat.
  5598. >> It's also one of the few copy-protection methods thats absolutely
  5599. >> compatible with the system and unlikely to fail in future releases.
  5600. >How do people feel about this technique.  Are there any obvious drawbacks?
  5601. >It does mean you need to "install" the software on each new system
  5602. >disk, any objections to this?
  5603.  
  5604. Actually, I really dislike the idea of having to install the software on
  5605. each new system, or being unable to switch to a different startup disk
  5606. (if say my startup volume died suddenly). I'd advocate a much different route
  5607. (which might be in use right now, since I've seen software behave this
  5608. way). Currently, a lot of software requires the user to do the first launch
  5609. on a writable volume in order to store registration information. As long
  5610. as it runs off of a read-only volume (ie a server) after that one registration
  5611. step, that doesn't bother me, and I don't think most users would be hassled
  5612. by this too much either. Consequently, I'd consider doing the following -
  5613. when prompting the user for registration information (which would be stored
  5614. inside the app), also look at the date/time of initialization of the
  5615. volume CONTAINING THE APP, and also look at the fileID of the app itself
  5616. (ie manually build a mini alias). Then store this information with the
  5617. registration information inside the app, and check against it at app
  5618. launch. This way, you can detect if the app file itself has been copied,
  5619. and reprompt for registration info if this is the case. The method is
  5620. flexible enough that if you wanted to allow some variants of copying
  5621. (ie doing a duplicate on the app file in the finder), you could check that
  5622. the app the reg info specifies is present and meets some basic checks
  5623. (as opposed to requiring that the app you are RUNNING is the app the reg
  5624. info points to). The other drawback is that this requires installation of
  5625. software on read-only servers by users with write permission - but this
  5626. requirement is present currently anyway.
  5627.  
  5628. Comments?
  5629.  
  5630. -Ivan
  5631. - -
  5632. Ivan Cavero Belaunde (ivanski@world.std.com)
  5633. Avid VideoShop Project Lead
  5634. Avid Technology, Inc.
  5635.  
  5636. +++++++++++++++++++++++++++
  5637.  
  5638. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  5639. Date: Tue, 8 Mar 94 09:16:22 PST
  5640. Organization: Peirce Software, Inc.
  5641.  
  5642.  
  5643. In article <1994Mar7.150036.11171@midway.uchicago.edu> (comp.sys.mac.programmer), ajr3@quads.uchicago.edu (Alain Roy) writes:
  5644. > In article <u9119523-070394123244@graphics1.sys.uea.ac.uk> u9119523@sys.uea.ac.uk (Graham Cox) writes:
  5645. > >
  5646. > >Here's a simple way. Get the Date/Time of initialization of the startup
  5647. > >disk. As this is accurate to the second, the chance of two Macs having
  5648. > >their hard disks initialised at the same time is very small.
  5649. > works unless you're like me: i have 2 hard drives. if every time i switched,
  5650. > i had the copy protection of a program fire up, i'd be really upset.
  5651.  
  5652. But this would only happen the first time you started up on your second
  5653. disk.  After that, its prefs file would contain the init time of *that*
  5654. disk.
  5655.  
  5656.  
  5657. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  5658. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  5659. --                       -- San Jose, California USA 95117
  5660. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  5661. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  5662.  
  5663. +++++++++++++++++++++++++++
  5664.  
  5665. >From time@garnet.msen.com (Tim Endres)
  5666. Date: 8 Mar 1994 18:47:42 GMT
  5667. Organization: Msen, Inc. -- Ann Arbor, MI (account info: +1 313 998-4562)
  5668.  
  5669. I really like Ivan's idea of storing the time for the disk
  5670. that the *app* is on. This solves Peter's network installation
  5671. problems and it solves CD and server setups.
  5672.  
  5673. +++++++++++++++++++++++++++
  5674.  
  5675. >From mahboud@aggroup.com (Mahboud Zabetian)
  5676. Date: Tue, 08 Mar 1994 11:37:13 -0800
  5677. Organization: AG Group, Inc.
  5678.  
  5679.  
  5680. For macs with built-in Ethernet;  Ethernet addresses are unique.
  5681.  
  5682. -mahboud
  5683. - -------------------------------------------------------------
  5684. Mahboud Zabetian
  5685. mahboud@aggroup.com
  5686. ag group, inc.
  5687. 2540 camino diablo, suite 200
  5688. walnut creek, ca 94596
  5689. 510-937-7900 voice
  5690. 510-937-2479 fax
  5691. 510-937-6704 ara
  5692. ftp.aggroup.com anonymous ftp
  5693.  
  5694. +++++++++++++++++++++++++++
  5695.  
  5696. >From Carl R. Osterwald <carl_osterwald@nrel.gov>
  5697. Date: Tue, 8 Mar 94 20:41:45 GMT
  5698. Organization: National Renewable Energy Laboratory
  5699.  
  5700. In article <mahboud-080394113713@mahboud.aggroup.com> Mahboud Zabetian,
  5701. mahboud@aggroup.com writes:
  5702. >For macs with built-in Ethernet;  Ethernet addresses are unique.
  5703.  
  5704. True, but what about machines that use Ethernet cards?  If the card is
  5705. changed for some reason, the nice app you spent good cash for no longer
  5706. runs.
  5707.  
  5708. +++++++++++++++++++++++++++
  5709.  
  5710. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  5711. Date: 8 Mar 1994 21:16:28 GMT
  5712. Organization: Royal Institute of Technology, Stockholm, Sweden
  5713.  
  5714. In <CNjbKKKX.q1oh3b@outpost.SF-Bay.org> peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  5715.  
  5716. >It does mean you need to "install" the software on each new system
  5717. >disk, any objections to this?
  5718.  
  5719. Not popular among large sites.
  5720.  
  5721. There is a way that an application can sense it's KeyServer
  5722. keyed and turn off its internal copy protection, though.
  5723. -- 
  5724.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  5725.  
  5726.     I should have stayed at the bus station.
  5727.  
  5728. +++++++++++++++++++++++++++
  5729.  
  5730. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  5731. Date: Wed, 9 Mar 1994 00:37:18 GMT
  5732. Organization: Proteus Ventures, Inc.
  5733.  
  5734. In article <A9A2311939027D1A@cro.nrel.gov>
  5735. Carl R. Osterwald <carl_osterwald@nrel.gov> writes:
  5736.  
  5737. > In article <mahboud-080394113713@mahboud.aggroup.com> Mahboud Zabetian,
  5738. > mahboud@aggroup.com writes:
  5739. > >For macs with built-in Ethernet;  Ethernet addresses are unique.
  5740. > True, but what about machines that use Ethernet cards?  If the card is
  5741. > changed for some reason, the nice app you spent good cash for no longer
  5742. > runs.
  5743.  
  5744. The ethernet address would still be the same. The address is assigned
  5745. to the machine and not to the card. The address is kept by the Mac TCP
  5746. software. (and can ussually be typed in by the user)
  5747.  
  5748. Addresses can and do change for other reasons, though. Administrators
  5749. can reassign addresses, the ethernet class could change, the machine
  5750. could be moved to a different network, etc.
  5751.  
  5752. Juan Ingles
  5753. <DACRXL01.OURX124@tcp30.dx.deere.com>
  5754. --
  5755. Proteus Ventures, Inc. - Computer Software Consulting and Development
  5756.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  5757.  
  5758. +++++++++++++++++++++++++++
  5759.  
  5760. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  5761. Date: 9 Mar 1994 11:48:59 +0800
  5762. Organization: NCRPDA, Curtin University
  5763.  
  5764. ivanski@world.std.com (Ivan M CaveroBelaunde) writes:
  5765.  
  5766. >Actually, I really dislike the idea of having to install the software on
  5767. >each new system, or being unable to switch to a different startup disk
  5768. >(if say my startup volume died suddenly). I'd advocate a much different route
  5769. >(which might be in use right now, since I've seen software behave this
  5770. >way). Currently, a lot of software requires the user to do the first launch
  5771. >on a writable volume in order to store registration information. As long
  5772.  
  5773. The problem with both these solutions is they are a pain to setup in a 
  5774. network environment, and since multiple copy licenses make up a large
  5775. chunk of the revenue, it really doesn't do to piss of these people with
  5776. anoying copy protection pains.
  5777.  
  5778. I don't mind software that asks you to register it with a serial number and
  5779. your name when you first install it, but if I have to do that for all
  5780. twenty copies that I bought, I wont buy them in the first place.
  5781.  
  5782. Piracy loses sales, but so does copy protection.
  5783.    Peter.
  5784. -- 
  5785. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  5786.  
  5787. +++++++++++++++++++++++++++
  5788.  
  5789. >From ari@world.std.com (Ari I Halberstadt)
  5790. Date: Wed, 9 Mar 1994 07:31:34 GMT
  5791. Organization: The World Public Access UNIX, Brookline, MA
  5792.  
  5793. In article <2lf445$5qd@lastactionhero.rs.itd.umich.edu>,
  5794. Matt Slot  <fprefect@engin.umich.edu> wrote:
  5795. >OK, off the podium. If you still need to identify a Mac from another,
  5796. >use the Volume Creation date for VRefNum = -1. This is the long date
  5797. >to the second of the initialization of that HD. For a 1 in 4 billion
  5798. >chance of duplication, this works rather well. If the user *does*
  5799. >reformat the boot disk, it will probably be a full reinstall and for
  5800. >all intents a "new" machine.
  5801.  
  5802. We can assume that all Macintosh hard drives have been formatted no
  5803. earlier than 1983 and no later than 1994 (assuming the user remembered
  5804. to set the clock before formatting). This gives a range of about
  5805. 3.47x10^8 seconds, or 347 million. Most drives have probably been
  5806. formatted in only the last 4 years (there weren't even hard drives for
  5807. the mac until '85, I think), so it's probably more like 1.26x10^8
  5808. seconds.  This is still a big number, but it's not nearly in the
  5809. billions.
  5810. -- 
  5811. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  5812. "These beetles were long considered to be very rare because very few
  5813. entomologists look for beetles in the mountains, in winter, at night,
  5814. during snow storms." -- Purves W. K., et al, "Life: The Science of
  5815.  
  5816. +++++++++++++++++++++++++++
  5817.  
  5818. >From dwalton1@bach.helios.nd.edu (david walton)
  5819. Date: 9 Mar 1994 08:21:54 GMT
  5820. Organization: University of Notre Dame, Notre Dame
  5821.  
  5822. In article <CMDGE6.5zt@deere.com> DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles) writes:
  5823. >In article <A9A2311939027D1A@cro.nrel.gov>
  5824. >Carl R. Osterwald <carl_osterwald@nrel.gov> writes:
  5825. >
  5826. >> In article <mahboud-080394113713@mahboud.aggroup.com> Mahboud Zabetian,
  5827. >> mahboud@aggroup.com writes:
  5828. >> >For macs with built-in Ethernet;  Ethernet addresses are unique.
  5829. >> 
  5830. >> True, but what about machines that use Ethernet cards?  If the card is
  5831. >> changed for some reason, the nice app you spent good cash for no longer
  5832. >> runs.
  5833. >
  5834. >The ethernet address would still be the same. The address is assigned
  5835. >to the machine and not to the card. The address is kept by the Mac TCP
  5836. >software. (and can ussually be typed in by the user)
  5837.  
  5838. *Ethernet* addresses are assigned to the physical hardware on the card
  5839. (which card may be moved around from machine to machine).  *IP
  5840. addresses* (which I think is what you mean) are configurable by the
  5841. MacTCP Control Panel and can therefore be changed by any user
  5842. (although AdminTCP may be required if the network administrator was
  5843. smart enough to lock the settings). If some form of BOOTP is used,
  5844. then the administrator controls which interface gets which address,
  5845. but the user can always configure MacTCP to use a static address.
  5846. (Which address, btw, often ends up being one which was assigned to
  5847. another user--anyone who's dealt with the "this IP address is already
  5848. in use" message from MacTCP when some putz on your local network
  5849. steals an address will know exactly what I'm talking about).
  5850.  
  5851. Point is, you can't assume a fixed relationship between either
  5852. ethernet or IP addresses and a particular machine, except in the
  5853. limiting case where the ethernet hardware's built in.  Hence, this
  5854. would not be a reliable copy-protection scheme in the general case.
  5855.  
  5856. Not that I _want_ copy-protection, mind you....
  5857.  
  5858. Now that I think about it, it's not trivial to get the Ethernet
  5859. address on built-in hardware if the machine doesn't have a transceiver
  5860. with an active link attached.  (Is is possible to do this, BTW?  I
  5861. don't see any way of doing it by making MacTCP calls, but is there a
  5862. lower-level driver call that could return this information?)
  5863.  
  5864. David
  5865. --
  5866. {  David Walton  School:  Dept. of History and Philosophy of Science     }
  5867. {           Work:  Office of University Computing        }
  5868. {             Mail:  David.Walton.10@nd.edu            }
  5869. {  Any unquoted opinions expressed herein are...well...mine.  Pity.    }
  5870.  
  5871. +++++++++++++++++++++++++++
  5872.  
  5873. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  5874. Date: 9 Mar 1994 15:07:28 GMT
  5875. Organization: Royal Institute of Technology, Stockholm, Sweden
  5876.  
  5877. In <CMDGE6.5zt@deere.com> DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles) writes:
  5878.  
  5879. >> True, but what about machines that use Ethernet cards?  If the card is
  5880. >> changed for some reason, the nice app you spent good cash for no longer
  5881. >> runs.
  5882.  
  5883. >The ethernet address would still be the same. The address is assigned
  5884. >to the machine and not to the card. The address is kept by the Mac TCP
  5885. >software. (and can ussually be typed in by the user)
  5886.  
  5887. PLEASE get your facts straigt at least.
  5888.  
  5889. Ethernet addresses are hardcoded in the Ethernet card ROM, and no
  5890. two cards EVER have the same address.
  5891.  
  5892. The IP address is what's maintained by MacTCP. Totally different
  5893. beast. Even if you don't install MacTCP, the ethernet address is
  5894. there in the ethernet card (even if you turn off AppleTalk!)
  5895.  
  5896. Ethernet breaks. Motherboard break. Users upgrade software. If
  5897. you've GOT to have copy protection, and don't mind breaking on
  5898. PowerBook Duos, use an ADB dongle; safe & efficient, upgradable,
  5899. and the money you save by not being pirated should pay for the
  5900. dongle price; if you subscribe to that theory. (I do for some
  5901. special niche products I make)
  5902. -- 
  5903.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  5904.  
  5905.    What we need is a good GNU [...] licence manager implementation.
  5906.                      -- Raphael Manfredi
  5907.  
  5908. +++++++++++++++++++++++++++
  5909.  
  5910. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  5911. Date: Wed, 9 Mar 1994 16:49:05 GMT
  5912. Organization: Proteus Ventures, Inc.
  5913.  
  5914. In article <2lk0v2$oq3@news.nd.edu>
  5915. dwalton1@bach.helios.nd.edu (david walton) writes:
  5916.  
  5917. > *Ethernet* addresses are assigned to the physical hardware on the card
  5918. > (which card may be moved around from machine to machine).  *IP
  5919. > addresses* (which I think is what you mean) 
  5920.  
  5921. Yea, I meant IP. I'm not a hardware person, so I had never heard of
  5922. Ethernet adresses on the cards and assumed that the "adress" mentioned
  5923. was an IP address.
  5924.  
  5925. Juan Ingles
  5926. <DACRXL01.OURX124@tcp30.dx.deere.com>
  5927. --
  5928. Proteus Ventures, Inc. - Computer Software Consulting and Development
  5929.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  5930.  
  5931. +++++++++++++++++++++++++++
  5932.  
  5933. >From Paul Ferguson <pferguson@kaleida.com>
  5934. Date: 9 Mar 1994 19:06:06 GMT
  5935. Organization: Kaleida Labs, Inc.
  5936.  
  5937. In article <2lk0v2$oq3@news.nd.edu> david walton,
  5938. dwalton1@bach.helios.nd.edu writes:
  5939. > Now that I think about it, it's not trivial to get the Ethernet
  5940. > address on built-in hardware if the machine doesn't have a
  5941. transceiver
  5942. > with an active link attached.  (Is is possible to do this, BTW?  I
  5943. > don't see any way of doing it by making MacTCP calls, but is there
  5944. a
  5945. > lower-level driver call that could return this information?)
  5946.  
  5947. Yes, there is a device driver call to the EtherTalk driver to
  5948. return the Ethernet address.
  5949.  
  5950. All Ethernet cards have their Ethernet address PROM memory mapped
  5951. into the physical address space, but there is no standard for where
  5952. this may be.  Therefore, directly accessing the Ethernet address
  5953. is highly vendor dependent.
  5954.  
  5955. Also, there is a defined method for providing a "soft" Ethernet
  5956. address in a resource that will override the hardware Ethernet
  5957. address.
  5958.  
  5959. --fergy
  5960.  
  5961. - ------------------------------------------------------------------
  5962.   Paul Ferguson         | "It's a sick world, I'm a happy guy..."
  5963.   pferguson@kaleida.com |  
  5964. - ------------------------------------------------------------------
  5965.  
  5966. +++++++++++++++++++++++++++
  5967.  
  5968. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  5969. Date: Wed, 9 Mar 1994 23:05:51 GMT
  5970. Organization: Proteus Ventures, Inc.
  5971.  
  5972. In article <2lkong$k0c@news.kth.se>
  5973. d88-jwa@mumrik.nada.kth.se (Jon W‰tte) writes:
  5974.  
  5975. > >The ethernet address would still be the same. The address is assigned
  5976. > >to the machine and not to the card. The address is kept by the Mac TCP
  5977. > >software. (and can ussually be typed in by the user)
  5978. > PLEASE get your facts straigt at least.
  5979.  
  5980. Hey! My facts were straight! I was just talking about something
  5981. completly different than everyone else was! That's all! :)
  5982.  
  5983. (Is that the Topic Police I hear coming?.....)
  5984.  
  5985. Juan Ingles
  5986. <DACRXL01.OURX124@tcp30.dx.deere.com>
  5987. --
  5988. Proteus Ventures, Inc. - Computer Software Consulting and Development
  5989.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  5990. --
  5991. Yes, I understand that you understood what I said. What you don't
  5992. understand is that I didn't say what I meant.
  5993.  
  5994. +++++++++++++++++++++++++++
  5995.  
  5996. >From peterb@tcc.oecn.ohio.gov (Peter Bierman)
  5997. Date: Sun, 13 Mar 1994 22:32:50 GMT
  5998. Organization: Linworth Alternative HS
  5999.  
  6000. In article <2lih8e$l5b@nigel.msen.com>, time@garnet.msen.com (Tim Endres)
  6001. wrote:
  6002.  
  6003. > I really like Ivan's idea of storing the time for the disk
  6004. > that the *app* is on. This solves Peter's network installation
  6005. > problems and it solves CD and server setups.
  6006.  
  6007. But what if the user transfers the app to a different volume because of low
  6008. disk space? I do this all the time.
  6009.  
  6010. -- 
  6011.        Peter Bierman       \  The Metropolis  \ The most primitive part of
  6012. the
  6013. peterb@tcc.oecn.ohio.gov    \  (614)-846-1911  \   the brain concerns
  6014. itself
  6015.                              \  600MB Mac Files \     with the "Four F's":
  6016. "I've changed my mind, Hobbes \  FirstClass      \ Feeding, Fighting,
  6017. Fleeing,
  6018.  people are scum." --Calvin    \  Mac & Windows   \     and Reproduction.
  6019.  
  6020. +++++++++++++++++++++++++++
  6021.  
  6022. >From noah@apple.com (Noah Price)
  6023. Date: Thu, 10 Mar 1994 23:49:02 GMT
  6024. Organization: (not the opinions of) Apple Computer, Inc.
  6025.  
  6026. In article <CNjbKKKX.q3sn67@outpost.SF-Bay.org>, peirce@outpost.SF-Bay.org
  6027. (Michael Peirce) wrote:
  6028. > In article <1994Mar7.150036.11171@midway.uchicago.edu>, ajr3@quads.uchicago.edu (Alain Roy) writes:
  6029. > > 
  6030. > > works unless you're like me: i have 2 hard drives. if every time i switched,
  6031. > > i had the copy protection of a program fire up, i'd be really upset.
  6032. > But this would only happen the first time you started up on your second
  6033. > disk.  After that, its prefs file would contain the init time of *that*
  6034. > disk.
  6035.  
  6036. But what if he switches back and forth between the two disks often for
  6037. whatever reason?
  6038.  
  6039. noah
  6040.  
  6041. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  6042. Noah Price                    (not the opinions of) Apple Computer, Inc.
  6043. Macintosh AV Hardware                      20525 Mariani Ave., MS 60-TNT
  6044. noah@apple.com                                        Cupertino CA 95014
  6045.  
  6046. +++++++++++++++++++++++++++
  6047.  
  6048. >From zdelesde@vt.edu (Zac DeLesDernier)
  6049. Date: 18 Mar 1994 03:17:41 GMT
  6050. Organization: Virginia Tech
  6051.  
  6052.      I have a related question. I need a way to uniquely identify a
  6053. file, other than its name. This identifying mechanism should also work
  6054. for copies of a file. (i.e. A backup would have the same file id.) The
  6055. id should _not_ change if the file is renamed or moved. (I hope I am
  6056. making myself clear.) One idea I had was writing some bignum into the
  6057. VERS resource, but then I dont want this marking system to mangle
  6058. applications (or anything else that might have a valid VERS resource.)
  6059. Any ideas?
  6060.  
  6061. - -
  6062.  
  6063. Zac DeLesDernier
  6064. zdelesde@vt.edu
  6065.  
  6066. ---------------------------
  6067.  
  6068. >From bdiamand@netcom.com (Ben Diamand)
  6069. Subject: I know the Mac MM isn't reentrant, but:
  6070. Date: Thu, 10 Mar 1994 03:12:17 GMT
  6071. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  6072.  
  6073.  
  6074. I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6075. interrupt(read:completion routine/callBack)?  If the answer is no, would 
  6076. some mac guru care to post/email a way to let the Mac Memory Manager know 
  6077. that a handle no longer needs to locked?  I realize it's been a long time 
  6078. since the high byte was used for this purpose, but the same info's got to 
  6079. be somewhere, right?!  As a further question to the same person who tells 
  6080. me how to change this(assuming anyone does :) ), am I doomed in 
  6081. native/emulated PowerPC using whatever means you give me to change this 
  6082. attribute?
  6083.  
  6084. Thanks!
  6085.  
  6086. Ben Diamand
  6087. bdiamand@netcom.com
  6088. ALINK:bdiamand
  6089.  
  6090.  
  6091. +++++++++++++++++++++++++++
  6092.  
  6093. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  6094. Date: Wed, 09 Mar 1994 23:07:59 -0600
  6095. Organization: University of Illinois at Urbana-Champaign
  6096.  
  6097. In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6098. Diamand) wrote:
  6099.  
  6100. >I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6101. >interrupt(read:completion routine/callBack)?
  6102.  
  6103. HUnlock is not on the list of routines that cannot be called at interrupt
  6104. time. It should be safe.
  6105.  
  6106. pr
  6107. -- 
  6108. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  6109. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  6110. System manager - Cognitive Science Group, Beckman Institute, UIUC
  6111. Internet: resnick@cogsci.uiuc.edu
  6112.  
  6113. +++++++++++++++++++++++++++
  6114.  
  6115. >From bdiamand@netcom.com (Ben Diamand)
  6116. Date: Thu, 10 Mar 1994 07:25:56 GMT
  6117. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  6118.  
  6119. Pete Resnick (resnick@cogsci.uiuc.edu) wrote:
  6120. : In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6121. : Diamand) wrote:
  6122.  
  6123. : >I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6124. : >interrupt(read:completion routine/callBack)?
  6125.  
  6126. : HUnlock is not on the list of routines that cannot be called at interrupt
  6127. : time. It should be safe.
  6128.  
  6129. Thank-you for the reply...Ya, I know that it's not on the list.  But, I
  6130. have great fear regarding interrupts and the MM, Sound Manager, and the
  6131. File Manager.  They all use interrupts to get their respective jobs done
  6132. and they all are incorrectly documented with respect to interrupts in
  6133. various versions of IM.  Sound Manager 3.0 seems to fix many problems that
  6134. I had with sound interrupts, but I stiil am very leary(sp?) of the Mac MM. 
  6135. Maybe I'm a Unix person at heart?  :)
  6136.  
  6137. Ben Diamand
  6138. bdiamand@netcom.com
  6139. ALINK:bdiamand
  6140.  
  6141.  
  6142. +++++++++++++++++++++++++++
  6143.  
  6144. >From gurgle@netcom.com (Pete Gontier)
  6145. Date: Thu, 10 Mar 1994 17:52:59 GMT
  6146. Organization: cellular
  6147.  
  6148. resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  6149.  
  6150. >In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6151. >Diamand) wrote:
  6152.  
  6153. >>I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6154. >>interrupt(read:completion routine/callBack)?
  6155.  
  6156. >HUnlock is not on the list of routines that cannot be called at interrupt
  6157. >time. It should be safe.
  6158.  
  6159. Apple has now disowned that list. Apple says that although there are
  6160. traps which can be called at interrupt time, the list is out of date.
  6161.  
  6162. In particular, I can imagine HUnlock being one of the traps that would
  6163. fail or misbehave at interrupt time. If the handle's flags were kept
  6164. in a prefix to the buffer rather than in the master pointer list, the
  6165. Memory Manager could be in the middle of shuffling that block when
  6166. HUnlock occurred, and the master pointer might not be updated yet. I'm
  6167. not sure, but I think this may be possible in a 32-bit heap. In any
  6168. case, it's not something I would want to rely on. Apple is changing the
  6169. implementation of the Memory Manager under System 7 for PowerPC, which
  6170. means there will be at least 3 known major versions of the MM. Since the
  6171. MM is one of the most sensitive areas with regard to interrupt time, I
  6172. wouldn't push my luck.
  6173.  
  6174. But now I'm curious -- why would you want to unlock a handle at
  6175. interrupt time?
  6176. -- 
  6177.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  6178.  
  6179. +++++++++++++++++++++++++++
  6180.  
  6181. >From ivanski@world.std.com (Ivan M CaveroBelaunde)
  6182. Date: Thu, 10 Mar 1994 15:28:20 GMT
  6183. Organization: The World Public Access UNIX, Brookline, MA
  6184.  
  6185. resnick@cogsci.uiuc.edu (Pete Resnick) writes:
  6186. >In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6187. >Diamand) wrote:
  6188. >>I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6189. >>interrupt(read:completion routine/callBack)?
  6190. >HUnlock is not on the list of routines that cannot be called at interrupt
  6191. >time. It should be safe.
  6192.  
  6193. Actually, the list is described as "routines that move memory." I don't
  6194. believe this implies that all other routines can be called at interrupt
  6195. time - certainly reentrancy can be an issue even for routines that do not
  6196. move memory. I'd be a little queasy about unlocking a handle from
  6197. interrupt time, for a couple of reasons:
  6198.     o In the best of cases, that handle must be locked. It's
  6199.         perfectly legal to unlock an unlocked handle, but
  6200.         if done at interrupt time you would hose yourself
  6201.         badly. I'd do an HGetState before that - of course,
  6202.         I'm not sure whether it's safe to call HGetState
  6203.         on an unlocked block during interrupt time in
  6204.         the first place, so unless it's always locked or
  6205.         you keep parallel state somewhere alse (ie global
  6206.         storage) this becomes a catch-22.
  6207.     o Non-reentrancy of the memory manager. I believe the memory manager
  6208.         uses private pieces of low memory for temporary storage,
  6209.         which might get nuked if you call HUnlock in the middle
  6210.         of another mem mgr operation. Also, while I don't know
  6211.         whether the "old" memory manager checks handle validity
  6212.         on an HUnlock operation (by walking the free master pointer
  6213.         lists, a no-no at interrupt time), the "new" memory manager
  6214.         that has appeared on developer CDs in prerelease version
  6215.         can be placed into a mode that performs that check.
  6216.     o Patches. There are probably more than a few INITs/extensions out
  6217.         there that patch HUnlock and do their own thing. While it
  6218.         is completely illegal for them to move memory in their
  6219.         patch, whether they could assume that the heaps are in
  6220.         a consistent state (an invalid assumption at interrupt time)
  6221.         is a gray area. Coupled with the fact that if your app
  6222.         is incompatible with a popular extension, it will be your
  6223.         app that is blamed, not that extension (unless the extension
  6224.         is known as a particularly troublesome one), this'd make
  6225.         me very wary.
  6226.  
  6227. For what it's worth, I wouldn't do it. I'd set a global flag and do it
  6228. from interrupt safe-land (like the event loop).
  6229.  
  6230. -Ivan
  6231. - -
  6232. Ivan Cavero Belaunde (ivanski@world.std.com)
  6233. Avid VideoShop Project Lead
  6234. Avid Technology, Inc.
  6235.  
  6236. +++++++++++++++++++++++++++
  6237.  
  6238. >From mgr@aggroup.aggroup.com (Mike Russell)
  6239. Date: Thu, 10 Mar 1994 12:05:29 -0800
  6240. Organization: the ag group, inc.
  6241.  
  6242. In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6243. Diamand) wrote:
  6244.  
  6245. > I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6246. > interrupt(read:completion routine/callBack)?
  6247.  
  6248. YOW - even if it's otherwise legal, consider the problems the following
  6249. non-interrupt code could run into if myHandle is unlocked asynchronously:
  6250.  
  6251.      SignedByte s = HGetState(myHandle);
  6252.      HLock(myHandle);
  6253.      ... Do some stuff ...
  6254.      HSetState(myHandle, s);
  6255.  
  6256. So be very careful about who else might be looking at the locked block.
  6257. A safer way to do this - DTInstall(), IM V-467.
  6258.  
  6259. +++++++++++++++++++++++++++
  6260.  
  6261. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  6262. Date: 11 Mar 1994 02:03:15 GMT
  6263. Organization: University of Illinois at Urbana
  6264.  
  6265. mgr@aggroup.aggroup.com (Mike Russell) writes:
  6266.  
  6267. >So be very careful about who else might be looking at the locked block.
  6268. >A safer way to do this - DTInstall(), IM V-467.
  6269.  
  6270. No, DTInstall won't help. Deferred tasks get executed at a time which
  6271. is effectively the same as interrupt time. It is no safer to call a
  6272. routine at deferred task time than at interrupt time.
  6273.  
  6274. pr
  6275. -- 
  6276. Pete Resnick             (...so what is a mojo, and why would one be rising?)
  6277. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  6278. System manager - Cognitive Science Group, Beckman Institute, UIUC
  6279. Internet: resnick@cogsci.uiuc.edu
  6280.  
  6281. +++++++++++++++++++++++++++
  6282.  
  6283. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  6284. Date: 11 Mar 1994 02:10:29 GMT
  6285. Organization: University of Illinois at Urbana
  6286.  
  6287. ivanski@world.std.com (Ivan M CaveroBelaunde) writes:
  6288.  
  6289. >Actually, the list is described as "routines that move memory."
  6290.  
  6291. No, the list at the end of the second edition of the X-Ref is
  6292. "routines that can't be called at interrupt." Some of them move
  6293. memory; some of them aren't reentrant.
  6294.  
  6295. pr
  6296. -- 
  6297. Pete Resnick             (...so what is a mojo, and why would one be rising?)
  6298. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  6299. System manager - Cognitive Science Group, Beckman Institute, UIUC
  6300. Internet: resnick@cogsci.uiuc.edu
  6301.  
  6302. +++++++++++++++++++++++++++
  6303.  
  6304. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  6305. Date: Fri, 11 Mar 1994 12:14:37 +0800
  6306. Organization: Department of Computer Science, The University of Western Australia
  6307.  
  6308. In article <resnick-090394230759@colt-17.slip.uiuc.edu>,
  6309. resnick@cogsci.uiuc.edu (Pete Resnick) wrote:
  6310.  
  6311. >In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6312. >Diamand) wrote:
  6313. >
  6314. >>I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6315. >>interrupt(read:completion routine/callBack)?
  6316. >
  6317. >HUnlock is not on the list of routines that cannot be called at interrupt
  6318. >time. It should be safe.
  6319.  
  6320. I hate to be picky but this is ***RONG!!!!***
  6321.  
  6322. If you don't believe me read Kon & Bal's puzzle page in develop 16.
  6323. Here's an extract....
  6324.  
  6325. - --------------------
  6326.         Mike    The interesting part of the heap before and after the
  6327. MoveHHi call is shown in the figure. Before MoveHHi there was a locked
  6328. block, labeled A in the figure, which is marked as relocatable afterward.
  6329. The relocatable block just below locked block B is getting overwritten by
  6330. the block weπre calling MoveHHi on. 
  6331.         KON     MoveHHi works by first saving the contents of the block
  6332. that youπre moving, then marking the block as free. Then it calls
  6333. CompactMem on the heap, which bubbles all the free space up to any islands
  6334. and all relocatable blocks down. Then it copies the block to the free
  6335. block just before the island. 
  6336.         BAL     And someone is coming in at interrupt time and unlocking
  6337. the island, block A in the figure. Instead of remembering the location of
  6338. the island, MoveHHi searches for it after the CompactMem call. Since that
  6339. block was unlocked by an interrupt after CompactMem, a different block is
  6340. found the second time. When MoveHHi backs up to the previous, presumably
  6341. free, block and starts copying data, the heap gets trashed.
  6342.         Mike    Yeah, that interrupt unlocking the block was QuickTime,
  6343. BAL. It turns out the Sound Manager does the same thing. Apparently the
  6344. ≥system architects≤ at the time thought it was OK to call HUnlock on a
  6345. locked block during an interrupt. Not! We fixed it by deferring all
  6346. HUnlock calls until MoveHHi finishes. This was the cleanest fix; it keeps
  6347. us from patching out huge parts of the Memory Manager. But we were stumped
  6348. for quite a while. 
  6349.         KON     Nasty.
  6350.         BAL     Yeah.
  6351. - --------------------
  6352.  
  6353. I'm sorry about the formatting but I cut and pasted it out of the
  6354. magazine on the CD.  Please read the article for a better explanation.
  6355.  
  6356. -- 
  6357. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  6358. Department of Computer Science, The University of Western Australia
  6359.   I hate newsreaders that complain about more quoted text than article
  6360.   text.  My quotes weren't from another article.  Grrrrr!!!!!
  6361.  
  6362. +++++++++++++++++++++++++++
  6363.  
  6364. >From bdiamand@netcom.com (Ben Diamand)
  6365. Date: Fri, 11 Mar 1994 07:41:42 GMT
  6366. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  6367.  
  6368. Mike Russell (mgr@aggroup.aggroup.com) wrote:
  6369. : In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6370. : Diamand) wrote:
  6371.  
  6372. : > 
  6373. : > I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6374. : > interrupt(read:completion routine/callBack)?
  6375.  
  6376. : YOW - even if it's otherwise legal, consider the problems the following
  6377. : non-interrupt code could run into if myHandle is unlocked asynchronously:
  6378.  
  6379. :      SignedByte s = HGetState(myHandle);
  6380. :      HLock(myHandle);
  6381. :      ... Do some stuff ...
  6382. :      HSetState(myHandle, s);
  6383.  
  6384. : So be very careful about who else might be looking at the locked block.
  6385. : A safer way to do this - DTInstall(), IM V-467.
  6386.  
  6387. My non-interrupt code locks the handle as soon as it gets it and then 
  6388. 'forgets' about the handle.  The interrupt code handles the handles:)
  6389.  
  6390. Ben Diamand
  6391. bdiamand@netcom.com
  6392. ALINK:bdiamand
  6393.  
  6394.  
  6395. +++++++++++++++++++++++++++
  6396.  
  6397. >From bdiamand@netcom.com (Ben Diamand)
  6398. Date: Fri, 11 Mar 1994 07:46:12 GMT
  6399. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  6400.  
  6401. Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote:
  6402. : In article <resnick-090394230759@colt-17.slip.uiuc.edu>,
  6403. : resnick@cogsci.uiuc.edu (Pete Resnick) wrote:
  6404.  
  6405. : >In article <bdiamandCMFI8H.K7o@netcom.com>, bdiamand@netcom.com (Ben
  6406. : >Diamand) wrote:
  6407. : >
  6408. : >>I know the Mac MM isn't reentrant, but, can I call HUnlock from within an 
  6409. : >>interrupt(read:completion routine/callBack)?
  6410. : >
  6411. : >HUnlock is not on the list of routines that cannot be called at interrupt
  6412. : >time. It should be safe.
  6413.  
  6414. : I hate to be picky but this is ***RONG!!!!***
  6415.  
  6416. : If you don't believe me read Kon & Bal's puzzle page in develop 16. :
  6417. Here's an extract.... 
  6418.  
  6419. [text deleted]
  6420. : ----------------------
  6421. :         Mike    Yeah, that interrupt unlocking the block was QuickTime,
  6422. : BAL. It turns out the Sound Manager does the same thing. Apparently the
  6423. : ≥system architects≤ at the time thought it was OK to call HUnlock on a
  6424. : locked block during an interrupt. Not! We fixed it by deferring all
  6425. : HUnlock calls until MoveHHi finishes. This was the cleanest fix; it keeps
  6426. : us from patching out huge parts of the Memory Manager. But we were stumped
  6427. : for quite a while. 
  6428. :         KON     Nasty.
  6429. :         BAL     Yeah.
  6430. : ----------------------
  6431.  
  6432. : I'm sorry about the formatting but I cut and pasted it out of the
  6433. : magazine on the CD.  Please read the article for a better explanation.
  6434.  
  6435. : -- 
  6436. : Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  6437. : Department of Computer Science, The University of Western Australia
  6438. :   I hate newsreaders that complain about more quoted text than article
  6439. :   text.  My quotes weren't from another article.  Grrrrr!!!!!
  6440.  
  6441. Ok, now here's a stupid question.  How does one know when MoveHHi is done?
  6442. I don't mind terribly defering the HUnlock...I just wanted to know if I 
  6443. had to...Thanks forthe reply...
  6444.  
  6445. Ben Diamand
  6446. bdiamand@netcom.com
  6447. ALINK:bdiamand
  6448.  
  6449.  
  6450. +++++++++++++++++++++++++++
  6451.  
  6452. >From Duane Murphy <damurphy@wc.novell.com>
  6453. Date: Mon, 14 Mar 1994 16:14:32 GMT
  6454. Organization: Novell, Inc.
  6455.  
  6456. In article <bdiamandCMFI8H.K7o@netcom.com> Ben Diamand,
  6457. bdiamand@netcom.com writes:
  6458. >I know the Mac MM isn't reentrant, but, can I call HUnlock from within
  6459. an 
  6460. >interrupt(read:completion routine/callBack)?  If the answer is no, would 
  6461. Ben,
  6462. There is a great article in develop issue 16 in KON & BAL's Puzzle Page 
  6463. that talks about just this problem. I just read it last week. Even the 
  6464. guru's at Apple think that HUnlock can be called at interrupt time. 
  6465.  
  6466. The problem stems from the algorithm used for MoveHHI. I don't 
  6467. quite understand it enough to explain it, but if the handle gets unlocked 
  6468. at the wrong time then MoveHHI will overwrite the handle.
  6469.  
  6470. Check out the article, it is pretty interesting (especially for debugging 
  6471. techniques).
  6472.  
  6473. Later,
  6474. ...Duane
  6475.  
  6476.   +------------------------+--------------------------------------------+
  6477.   | Duane Murphy           | My opinions are mine, mine, and only mine; |
  6478.   | damurphy@wc.novell.com |      Except when they are also yours.      |
  6479.   +------------------------+--------------------------------------------+
  6480.  
  6481. +++++++++++++++++++++++++++
  6482.  
  6483. >From Steve Ethier <ethier@wc.novell.com>
  6484. Date: Mon, 14 Mar 1994 18:03:43 GMT
  6485. Organization: Novell, Inc.
  6486.  
  6487. In article <1994Mar14.161432.18054@novell.com> Duane Murphy,
  6488. damurphy@wc.novell.com writes:
  6489. >In article <bdiamandCMFI8H.K7o@netcom.com> Ben Diamand,
  6490. >bdiamand@netcom.com writes:
  6491. >>I know the Mac MM isn't reentrant, but, can I call HUnlock from within
  6492. >an 
  6493. >>interrupt(read:completion routine/callBack)?  If the answer is no,
  6494. would 
  6495. >Ben,
  6496. >There is a great article in develop issue 16 in KON & BAL's Puzzle Page 
  6497. >that talks about just this problem. I just read it last week. Even the 
  6498. >guru's at Apple think that HUnlock can be called at interrupt time. 
  6499. >
  6500. >The problem stems from the algorithm used for MoveHHI. I don't 
  6501. >quite understand it enough to explain it, but if the handle gets
  6502. unlocked 
  6503. >at the wrong time then MoveHHI will overwrite the handle.
  6504. >
  6505. >Check out the article, it is pretty interesting (especially for
  6506. debugging 
  6507. >techniques).
  6508. >
  6509. >Later,
  6510. >...Duane
  6511.  
  6512. Ben, the "short form" to Duane's answer is that HUnlock is *not* safe to
  6513. call at interrupt time.  (Duane let me read the article, and I must admit
  6514. that it is indeed very interesting.)
  6515.  
  6516. Steve Ethier
  6517. ethier@wc.novell.com
  6518.  
  6519. +++++++++++++++++++++++++++
  6520.  
  6521. >From David A Lyons <dlyons@apple.com>
  6522. Date: Thu, 10 Mar 1994 22:26:21 GMT
  6523. Organization: Apple Computer, Inc.
  6524.  
  6525. In article <gurgleCMGn0B.F87@netcom.com> Pete Gontier,
  6526. gurgle@netcom.com writes:
  6527. > In particular, I can imagine HUnlock being one of the traps that
  6528. would
  6529. > fail or misbehave at interrupt time.
  6530.  
  6531. Correct, calling HUnlock at interrupt time is bad.  See Kon and Bal's
  6532. Puzzle Page in _develop_ #16 (December 1993).
  6533.  
  6534. Dave Lyons, dlyons@apple.com
  6535. Mr Tangent
  6536.  
  6537. My opinions are my own, not Apple's.
  6538.  
  6539. ---------------------------
  6540.  
  6541. >From mahboud@aggroup.com (Mahboud Zabetian)
  6542. Subject: If you use SysBeep() for debugging...
  6543. Date: Wed, 23 Feb 1994 15:07:55 -0800
  6544. Organization: AG Group, Inc.
  6545.  
  6546. If you're like me and like to throw in SysBeep() calls in questionable code
  6547. to help determine program flow, be careful!
  6548.  
  6549. SysBeep() may move memory and could potentially make dereferenced handles
  6550. invalid!
  6551.  
  6552. This is a hard one to chase down, since you now have another bug added to
  6553. whatever bug you were originally looking for.
  6554.  
  6555. Hope this helps someone.  
  6556.  
  6557. -mahboud
  6558.  
  6559. - -------------------------------------------------------------
  6560. Mahboud Zabetian
  6561. mahboud@aggroup.com
  6562. ag group, inc.
  6563. 2540 camino diablo, suite 200
  6564. walnut creek, ca 94596
  6565. 510-937-7900 voice
  6566. 510-937-2479 fax
  6567. 510-937-6704 ara
  6568. ftp.aggroup.com anonymous ftp
  6569.  
  6570. +++++++++++++++++++++++++++
  6571.  
  6572. >From blume@twg.com (David Blume)
  6573. Date: Wed, 23 Feb 1994 23:56:35 GMT
  6574. Organization: Gokuraku Videos - Wollongong Dept.
  6575.  
  6576. mahboud@aggroup.com (Mahboud Zabetian) wrote:
  6577. >If you're like me and like to throw in SysBeep() calls in questionable code
  6578. >to help determine program flow, be careful!
  6579. >
  6580. >SysBeep() may move memory and could potentially make dereferenced handles
  6581. >invalid!
  6582.  
  6583. According to IM2, SysBeep() is stack-based.  Also, my handy-dandy Online
  6584. reference doesn't have the diamond character indicating that it moves
  6585. memory.
  6586.  
  6587. However, 411 does agree with Mahboud.  It says that SysBeep() does move
  6588. or purge memory.  Sneaky...
  6589.  
  6590. --David
  6591. +-------------------------------------------------------------------------+
  6592. | David Blume   | "A, Ayukawa!"    | "Moemichan! ... SUKIDA!!" -- Youta   |
  6593. | blume@twg.com | "Kasuga-kuun..." | "Suckerfish!"  -- Ai Amano           |
  6594. +-------------------------------------------------------------------------+
  6595.  
  6596. +++++++++++++++++++++++++++
  6597.  
  6598. >From danprice@delphi.com
  6599. Date: Wed, 23 Feb 94 19:51:33 -0500
  6600. Organization: Delphi (info@delphi.com email, 800-695-4005 voice)
  6601.  
  6602.  
  6603. Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6604.  
  6605. Has anyone had a problem w/ sysbeep() doing this?
  6606.  
  6607.     -dp
  6608.  
  6609. +++++++++++++++++++++++++++
  6610.  
  6611. >From mahboud@aggroup.com (Mahboud Zabetian)
  6612. Date: Wed, 23 Feb 1994 22:51:49 -0800
  6613. Organization: AG Group, Inc.
  6614.  
  6615. In article <1994Feb23.235635.17269@twg.com>, blume@twg.com (David Blume)
  6616. wrote:
  6617.  
  6618. > mahboud@aggroup.com (Mahboud Zabetian) wrote:
  6619. > >If you're like me and like to throw in SysBeep() calls in questionable code
  6620. > >to help determine program flow, be careful!
  6621. > >
  6622. > >SysBeep() may move memory and could potentially make dereferenced handles
  6623. > >invalid!
  6624. > According to IM2, SysBeep() is stack-based.  Also, my handy-dandy Online
  6625. > reference doesn't have the diamond character indicating that it moves
  6626. > memory.
  6627.  
  6628. Back in the days of the 128K and 512K mac, SysBeep() just played a good ole
  6629. beep.  A tone.
  6630.  
  6631. Now that it plays digitized sounds, it seems to do a GetResource and/or
  6632. LoadResource to get the sound.  You can verify with an A-Trap break (Don't
  6633. ATB on GetResource; Do an ATb for SysBeep, then when you are in the
  6634. debugger, setup an ATB GetResource.  You'll see 'snd ' on the stack).
  6635.  
  6636. > However, 411 does agree with Mahboud.  It says that SysBeep() does move
  6637. > or purge memory.  Sneaky...
  6638. > --David
  6639. > +-------------------------------------------------------------------------+
  6640. > | David Blume   | "A, Ayukawa!"    | "Moemichan! ... SUKIDA!!" -- Youta   |
  6641. > | blume@twg.com | "Kasuga-kuun..." | "Suckerfish!"  -- Ai Amano           |
  6642. > +-------------------------------------------------------------------------+
  6643.  
  6644. Sneaky is right.  I was been bitten by this one 3 years ago too.  Hard to
  6645. figure out.
  6646.  
  6647. -mahboud
  6648.  
  6649. - -------------------------------------------------------------
  6650. Mahboud Zabetian
  6651. mahboud@aggroup.com
  6652. ag group, inc.
  6653. 2540 camino diablo, suite 200
  6654. walnut creek, ca 94596
  6655. 510-937-7900 voice
  6656. 510-937-2479 fax
  6657. 510-937-6704 ara
  6658. ftp.aggroup.com anonymous ftp
  6659.  
  6660. +++++++++++++++++++++++++++
  6661.  
  6662. >From mahboud@aggroup.com (Mahboud Zabetian)
  6663. Date: Wed, 23 Feb 1994 22:58:58 -0800
  6664. Organization: AG Group, Inc.
  6665.  
  6666. In article <xu5p+Bd.danprice@delphi.com>, danprice@delphi.com wrote:
  6667.  
  6668. >  
  6669. > Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6670. >  
  6671. > Has anyone had a problem w/ sysbeep() doing this?
  6672. >  
  6673. >     -dp
  6674.  
  6675. Here's one way that I am trying out, but it's not audible like SysBeep().
  6676.  
  6677. I start at one end of my window and turn a pixel on.  Using SetCPixel, I
  6678. can setup the color too.
  6679.  
  6680. I was mainly interested in doing this from an interrupt handler (I never
  6681. checked to see if it moved memory, sorry), and it seemed to work fine,
  6682. except that it was slow compared to my interrupt handler, and was slowing
  6683. everything down.
  6684.  
  6685. Are there still LowMem globals reserved for apps to use?  If so, maybe the
  6686. application under test could write a status value into that global, and can
  6687. be checked at a later time?
  6688.  
  6689. Any other thoughts appreciated...
  6690.  
  6691. -mahboud
  6692.  
  6693. - -------------------------------------------------------------
  6694. Mahboud Zabetian
  6695. mahboud@aggroup.com
  6696. ag group, inc.
  6697. 2540 camino diablo, suite 200
  6698. walnut creek, ca 94596
  6699. 510-937-7900 voice
  6700. 510-937-2479 fax
  6701. 510-937-6704 ara
  6702. ftp.aggroup.com anonymous ftp
  6703.  
  6704. +++++++++++++++++++++++++++
  6705.  
  6706. >From pottier@corvette.ens.fr (Francois Pottier)
  6707. Date: 24 Feb 1994 10:39:07 GMT
  6708. Organization: Ecole Normale Superieure, PARIS, France
  6709.  
  6710. In article <mahboud-230294225858@mahboud.aggroup.com>,
  6711. Mahboud Zabetian <mahboud@aggroup.com> wrote:
  6712.  
  6713. >> Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6714.  
  6715. Why not use the DebugStr call ?
  6716. For instance, if I'm not mistaken, DebugStr('Checkpoint 1 ; g');
  6717. should print "Checkpoint 1" into Macsbug and resume execution.
  6718.  
  6719.  
  6720.  
  6721. -- 
  6722. Francois Pottier            ___ ___  _    _  / ___  ___    ___
  6723. pottier@dmi.ens.fr       /_  /__/ /_|  /| / /  / /  / / /__
  6724.               /   / \  /  | / |/ /___ /__/ / ___/ _
  6725.                           /
  6726.  
  6727. +++++++++++++++++++++++++++
  6728.  
  6729. >From tzs@u.washington.edu (Tim Smith)
  6730. Date: 24 Feb 1994 10:43:04 GMT
  6731. Organization: University of Washington School of Law, Class of '95
  6732.  
  6733. In article <xu5p+Bd.danprice@delphi.com>,  <danprice@delphi.com> wrote:
  6734. >Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6735.  
  6736. One thing I found real useful for debugging was to write my own printf
  6737. that wrote directly to screen memory.  It used a simple built in font
  6738. (with each character being 3x5--yes, you can actually make a legible
  6739. character set with 3x5--so that the memory manipulation would be easy).
  6740. With this, I could get debugging information from all kinds of places
  6741. where regular debug tools might fail: ethernet interrupt routines,
  6742. SCSI boot code, Nubus card interrupts, etc., and I didn't have to
  6743. worry about memory being moved, or managers not being in the proper
  6744. state, or whatever.
  6745.  
  6746. Unfortunately, I wrote this as part of my job, so I can't post it.
  6747.  
  6748. --Tim Smith
  6749.  
  6750. +++++++++++++++++++++++++++
  6751.  
  6752. >From kledbetter@aol.com (KLedbetter)
  6753. Date: 24 Feb 1994 13:34:01 -0500
  6754. Organization: America Online, Inc.
  6755.  
  6756. >>Wow, good point.  Any suggestions for an easy debugging tool like
  6757. >> sysbeep()?
  6758.  
  6759.  Well, if you're using C and System 7, you might want to look for my program
  6760. "DebugWindow 2.0".  It uses AppleEvents to easily display messages in a
  6761. debugging window.  Simply add DebugWindow.Lib to your project, and then you can
  6762. do things like:
  6763.  
  6764.    Debug ("Just starting so-and-so routine\r");
  6765.    .....
  6766.    Debug ("Value of index is now %d\r", index);
  6767.  
  6768. Keith
  6769.  
  6770.  
  6771. +++++++++++++++++++++++++++
  6772.  
  6773. >From perlis_a@math.lsu.edu (Alexander Perlis)
  6774. Date: 25 Feb 1994 00:47:14 GMT
  6775. Organization: Louisiana State University InterNetNews Site
  6776.  
  6777. In article <1994Feb23.235635.17269@twg.com> blume@twg.com (David Blume)  
  6778. writes:
  6779. > mahboud@aggroup.com (Mahboud Zabetian) wrote:
  6780. > >If you're like me and like to throw in SysBeep() calls in questionable  
  6781. code
  6782. > >to help determine program flow, be careful!
  6783. > >
  6784. > >SysBeep() may move memory and could potentially make dereferenced  
  6785. handles
  6786. > >invalid!
  6787. > According to IM2, SysBeep() is stack-based.  Also, my handy-dandy Online
  6788. > reference doesn't have the diamond character indicating that it moves
  6789. > memory.
  6790. > However, 411 does agree with Mahboud.  It says that SysBeep() does move
  6791. > or purge memory.  Sneaky...
  6792. > --David
  6793.  
  6794. I would presume that this inconsistency in the documentation has to do  
  6795. with changes to the SysBeep() trap after the Sound Manager was added to  
  6796. the system software a few years back. At that point, SysBeep() no longer  
  6797. accessed the speaker or low-level sound routines directly, but instead  
  6798. called the Sound Manager to play the current system beep sound. The Sound  
  6799. Manager, being complicated and supporting different sounds stored in  
  6800. various formats in resources, obviously moves memory to do its work.
  6801.  
  6802. At one point (when the Sound Manager first came out) it was still possible  
  6803. to call the original SysBeep() code. At least, if "System Beep" was the  
  6804. system beep sound, then SysBeep() would use its old code rather than  
  6805. calling the Sound Manager. In today's system software, however, there is  
  6806. an actual sound called "System Beep" and it gets played by the Sound  
  6807. Manager if it is the selected system beep sound. [Boy, this sounds like a  
  6808. bunch of double-talk. Is anyone able to follow this?]
  6809.  
  6810. Presumably, if the code of the original SysBeep() routine is still in ROM,  
  6811. one can call it somehow, and memory will not be moved. That would solve  
  6812. the problem of using beep sounds while debugging code which cannot move  
  6813. memory. I don't know how to call the original SysBeep() code, assuming it  
  6814. is even possible. Can any of the experts reading this thread shed some  
  6815. light on the matter?
  6816.  
  6817.  
  6818. Alexander Perlis, perlis_a@math.lsu.edu
  6819.  
  6820. +++++++++++++++++++++++++++
  6821.  
  6822. >From robert@tbit.com (RObert Abatecola)
  6823. Date: Thu, 24 Feb 94 17:55:06 PST
  6824. Organization: TBIT, WMCS chat/message BBS, San Jose, CA  (408)257-6225
  6825.  
  6826. >  Well, if you're using C and System 7, you might want to look for my program
  6827. > "DebugWindow 2.0".  It uses AppleEvents to easily display messages in a
  6828. > debugging window.  Simply add DebugWindow.Lib to your project, and then you 
  6829. > can
  6830. > do things like:
  6831. >    Debug ("Just starting so-and-so routine\r");
  6832. >    .....
  6833. >    Debug ("Value of index is now %d\r", index);
  6834.  
  6835. Any hints on where one might look for DebugWindow 2.0?
  6836.  
  6837. +++++++++++++++++++++++++++
  6838.  
  6839. >From pjcreath@tucson.Princeton.EDU (Peter Janssen Creath)
  6840. Date: Thu, 24 Feb 1994 21:10:06 GMT
  6841. Organization: Princeton University
  6842.  
  6843. In article <xu5p+Bd.danprice@delphi.com>,  <danprice@delphi.com> wrote:
  6844. >Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6845.  
  6846. My personal favorite is MacsBug in conjunction with Debugger() or
  6847. DebugStr("\pWhatever error message I want");
  6848.  
  6849. And it's free...(just hit "g" to resume)
  6850.  
  6851. And unless you're fiddling with low memory (and hosing the interrupt
  6852. table) it won't crash on you...
  6853.  
  6854.  
  6855. +++++++++++++++++++++++++++
  6856.  
  6857. >From blume@twg.com (David Blume)
  6858. Date: Fri, 25 Feb 1994 16:34:03 GMT
  6859. Organization: Gokuraku Videos - Wollongong Dept.
  6860.  
  6861. tzs@u.washington.edu (Tim Smith) wrote:
  6862. >One thing I found real useful for debugging was to write my own printf
  6863. >that wrote directly to screen memory. ... I didn't have to
  6864. >worry about memory being moved, or managers not being in the proper
  6865. >state, or whatever.
  6866.  
  6867. How did you draw characters directly to the screen without using a toolbox
  6868. routine that may have moved or purged memory?  Everything from DrawChar()
  6869. to CopyBits() might move memory...
  6870.  
  6871. --David
  6872. +---------------------------------------------------------------+
  6873. |  David Blume    |  "I get tired thinking of all the things I  |
  6874. |  blume@twg.com  |   don't want to do."  --Bukowski, _Barfly_  |
  6875. +---------------------------------------------------------------+
  6876.  
  6877. +++++++++++++++++++++++++++
  6878.  
  6879. >From bc@wetware.com (monsieur HAINEUX)
  6880. Date: Fri, 25 Feb 1994 19:20:09 GMT
  6881. Organization: /usr/local/lib/rn/organization
  6882.  
  6883. |In article <xu5p+Bd.danprice@delphi.com>,  <danprice@delphi.com> wrote:
  6884. |>Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6885.  
  6886. Use DebugStr(). Unless there's a reason you can't use MacsBug[1], it
  6887. works like a champ, and you get more feedback than SysBeep.
  6888.  
  6889. If you're REALLY clever, you can use a macro that includes an #ifdef
  6890. _DEBUG_ to automatically make the DebugStr's go away for production
  6891. code.
  6892.  
  6893. bill coderre
  6894. [1] Yes, there are cases where you cannot use MacsBug. Pray that they
  6895. never catch up to you.
  6896.  
  6897.  
  6898. +++++++++++++++++++++++++++
  6899.  
  6900. >From mahboud@aggroup.com (Mahboud Zabetian)
  6901. Date: Fri, 25 Feb 1994 12:16:16 -0800
  6902. Organization: AG Group, Inc.
  6903.  
  6904. In article <CLsoDL.Exu@wetware.com>, bc@wetware.com (monsieur HAINEUX)
  6905. wrote:
  6906.  
  6907. > |In article <xu5p+Bd.danprice@delphi.com>,  <danprice@delphi.com> wrote:
  6908. > |>Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6909. > Use DebugStr(). Unless there's a reason you can't use MacsBug[1], it
  6910. > works like a champ, and you get more feedback than SysBeep.
  6911. I do use Debugger() and DebugStr().  (In fact I also have use my own
  6912. DebugNum(), DebugHexNum() DebugBuffStr()....).
  6913.  
  6914. Yet there have been times that a SysBeep() is best.  For example:  A
  6915. customer complains that our applications doesn't do x.  I look and look and
  6916. look and look at the code and wonder: does it get to x and doesn't execute
  6917. it, or does it execute x and x is the problem, or is this user on drugs
  6918. since the code is OBVIOUSLY correct? (I don't write buggy code :-)  Well, I
  6919. add a quick SysBeep() before x and in x.  Then I send it to the customer
  6920. (who may or may not have MacsBug or who may or may not know what to do when
  6921. in MacsBug) and ask him:  "Does it beep when you try it?  Once or twice?"
  6922.  
  6923. You see, a Debugger() call would probably have been more of a hassle.
  6924.  
  6925. -mahboud
  6926.  
  6927. ps.   My favorite bug:
  6928.  
  6929.      handle = GetResource(.....);
  6930.      if (handle = nil) {
  6931.           // resource is there so do somthing with it.
  6932.      }
  6933.  
  6934. My next favorite bug:
  6935.       Calling InvalRect without a valid GrafPort set.
  6936.  
  6937. And:
  6938.      SetPort(window);  // where window is a random, garbage value on the
  6939. stack
  6940. - -------------------------------------------------------------
  6941. Mahboud Zabetian
  6942. mahboud@aggroup.com
  6943. ag group, inc.
  6944. 2540 camino diablo, suite 200
  6945. walnut creek, ca 94596
  6946. 510-937-7900 voice
  6947. 510-937-2479 fax
  6948. 510-937-6704 ara
  6949. ftp.aggroup.com anonymous ftp
  6950.  
  6951. +++++++++++++++++++++++++++
  6952.  
  6953. >From bc@wetware.com (monsieur HAINEUX)
  6954. Date: Fri, 25 Feb 1994 21:34:25 GMT
  6955. Organization: /usr/local/lib/rn/organization
  6956.  
  6957. In article <CLsoDL.Exu@wetware.com> bc@wetware.com (monsieur HAINEUX) writes:
  6958. ||In article <xu5p+Bd.danprice@delphi.com>,  <danprice@delphi.com> wrote:
  6959. ||>Wow, good point.  Any suggestions for an easy debugging tool like sysbeep()?
  6960. |
  6961. |Use DebugStr(). Unless there's a reason you can't use MacsBug[1], it
  6962. |works like a champ, and you get more feedback than SysBeep.
  6963. |
  6964. |If you're REALLY clever, you can use a macro that includes an #ifdef
  6965. |_DEBUG_ to automatically make the DebugStr's go away for production
  6966. |code.
  6967. |
  6968. |bill coderre
  6969. |[1] Yes, there are cases where you cannot use MacsBug. Pray that they
  6970. |never catch up to you.
  6971.  
  6972. Think Reference reminded me that DebugStr dumps you into the debugger,
  6973. but you can put a string like "Entering BugVille;g" and the semicolon
  6974. allows you to load up the rest of the string with MacsBug commands. In
  6975. this case, the screen will flicker briefly while Macsbug writes the
  6976. line, then the program will resume.
  6977.  
  6978. bill coderre
  6979. "Hard Problems made simple -- and vice versa"
  6980.     -- corporate motto of Symbolics
  6981.  
  6982.  
  6983. +++++++++++++++++++++++++++
  6984.  
  6985. >From mxmora@unix.sri.com (Matt Mora)
  6986. Date: 25 Feb 1994 10:08:13 -0800
  6987. Organization: SRI International, Menlo Park, CA
  6988.  
  6989. In article <1994Feb25.163403.14920@twg.com> blume@twg.com (David Blume) writes:
  6990. >tzs@u.washington.edu (Tim Smith) wrote:
  6991. >>One thing I found real useful for debugging was to write my own printf
  6992. >>that wrote directly to screen memory. ... I didn't have to
  6993. >>worry about memory being moved, or managers not being in the proper
  6994. >>state, or whatever.
  6995. >
  6996. >How did you draw characters directly to the screen without using a toolbox
  6997. >routine that may have moved or purged memory?  Everything from DrawChar()
  6998. >to CopyBits() might move memory...
  6999.  
  7000. He probably twiddled the bits directly. Which is why he said he was using
  7001. a 5 x 7 character set. He set each bit in the screen's bitmap himself.
  7002. Cool.
  7003.  
  7004.  
  7005. Xavier
  7006.  
  7007.  
  7008.  
  7009.  
  7010.  
  7011. -- 
  7012. ___________________________________________________________
  7013. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  7014. SRI International                       mxmora@unix.sri.com
  7015. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  7016.  
  7017. +++++++++++++++++++++++++++
  7018.  
  7019. >From monroe@teleport.com (Monroe Williams)
  7020. Date: 25 Feb 1994 17:00:18 -0800
  7021. Organization: Teleport - Portland's Public Access (503) 220-1016
  7022.  
  7023. In article <2kjhqi$2n70@te6000.otc.lsu.edu>,
  7024. Alexander Perlis <perlis_a@math.lsu.edu> wrote:
  7025. [...]
  7026. >Presumably, if the code of the original SysBeep() routine is still in ROM,  
  7027. >one can call it somehow, and memory will not be moved. That would solve  
  7028. >the problem of using beep sounds while debugging code which cannot move  
  7029. >memory. I don't know how to call the original SysBeep() code, assuming it  
  7030. >is even possible. Can any of the experts reading this thread shed some  
  7031. >light on the matter?
  7032.  
  7033. I doubt very much that any of the newer machines have the old SysBeep
  7034. code in them.  As you said, it's been done through the sound manager
  7035. for quite some time now.
  7036.  
  7037. However...
  7038.  
  7039. It should be possible to find the startup chime code in the ROMs.  I
  7040. seem to remember a little utility that plays the startup chime and
  7041. various error tones, apparently using the ROMs to do it.  Does anybody
  7042. out there know how this is done?  There are a couple of really
  7043. disturbing sounds a Mac can make (like when it fails the hardware RAM
  7044. diagnostic) that would definitely get your attention.  I can't imagine
  7045. these ROM routines would even require the memory manager, much less
  7046. move memory.
  7047.  
  7048. BTW (for the curious), on my SE/30 you can hear the error tones by
  7049. pressing the interrupt button on the programmer's switch while the
  7050. machine is doing the initial memory tests when you first switch it on.
  7051. I don't know if this trick works on newer machines that have the nicer
  7052. sounding startup chime, though.
  7053.  
  7054. - monroe
  7055. -- 
  7056. monroe@teleport.COM  Public Access User --- Not affiliated with TECHbooks
  7057. Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81)
  7058.  
  7059. +++++++++++++++++++++++++++
  7060.  
  7061. >From monroe@teleport.com (Monroe Williams)
  7062. Date: 25 Feb 1994 17:22:04 -0800
  7063. Organization: Teleport - Portland's Public Access (503) 220-1016
  7064.  
  7065. In article <CLsuLE.LBM@wetware.com>, monsieur HAINEUX <bc@wetware.com> wrote:
  7066. >In article <CLsoDL.Exu@wetware.com> bc@wetware.com (monsieur HAINEUX) writes:
  7067. >|If you're REALLY clever, you can use a macro that includes an #ifdef
  7068. >|_DEBUG_ to automatically make the DebugStr's go away for production
  7069. >|code.
  7070.  
  7071. Digressing just a bit...
  7072.  
  7073. It's pretty simple to make up a version of assert() that uses
  7074. DebugStr.  (Start with the assert.h that comes with your development
  7075. environment.  It's almost always implemented as a macro.)  With a few
  7076. preprocessor tricks, it will give you the file name and line number, as
  7077. well as the expression inside the assertion.  Real handy, especially
  7078. for porting code from unix that's full of asserts, when you're not
  7079. using console I/O.
  7080.  
  7081. - monroe
  7082. -- 
  7083. monroe@teleport.COM  Public Access User --- Not affiliated with TECHbooks
  7084. Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81)
  7085.  
  7086. +++++++++++++++++++++++++++
  7087.  
  7088. >From lewistot@netcom.com (John Lewis)
  7089. Date: Sat, 26 Feb 1994 04:22:56 GMT
  7090. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  7091.  
  7092. Mahboud Zabetian (mahboud@aggroup.com) wrote:
  7093. : SysBeep() may move memory and could potentially make dereferenced handles
  7094. : invalid!
  7095.  
  7096. You mean you don't lock your handles BEFORE you dereference them?
  7097.  
  7098. : This is a hard one to chase down, since you now have another bug added to
  7099. : whatever bug you were originally looking for.
  7100.  
  7101. Surround your dereferences with a LockHandle/UnlockHandle pair. This is
  7102. not only good programming practice, but it will also solve the problem
  7103. of SysBeep moving things around.
  7104. -- 
  7105. - -------------------------------------------------------------------------
  7106. John "I'ld rather be skydiving" Lewis|#include "standard .sig BS" |Witty  |
  7107. lewistot@netcom.com <- prefered      |Blue Skies to all skydivers.|text   |
  7108. jlewis@maxis.com    <- work          |USPA 87419, C-22826         |picture|
  7109. lewistotle@aol.com                   |<Fnord>                     |comming|
  7110.  
  7111. +++++++++++++++++++++++++++
  7112.  
  7113. >From kledbetter@aol.com (KLedbetter)
  7114. Date: 26 Feb 1994 13:25:02 -0500
  7115. Organization: America Online, Inc.
  7116.  
  7117. >    Debug ("Just starting so-and-so routine\r");
  7118. >    .....
  7119. >    Debug ("Value of index is now %d\r", index);
  7120.  
  7121. Any hints on where one might look for DebugWindow 2.0?
  7122. - --------
  7123. Robert --
  7124.  
  7125.   it's available on Compuserve in the MacDev forum, and on America Online in
  7126. the Mac Developers area.   It works really nice .. you can also do Hex dumps to
  7127. the window (ie: DebugHexDump (myBuffer, 1024)) and then print out the window's
  7128. contents, save as a teachtext document, etc..
  7129.  
  7130. Keith
  7131.  
  7132.  
  7133. +++++++++++++++++++++++++++
  7134.  
  7135. >From casgrain@ERE.UMontreal.CA (Casgrain Philippe)
  7136. Date: Sat, 26 Feb 1994 19:53:59 GMT
  7137. Organization: Universite de Montreal
  7138.  
  7139. >>    Debug ("Just starting so-and-so routine\r");
  7140. >>    .....
  7141. >>    Debug ("Value of index is now %d\r", index);
  7142. >
  7143. >Any hints on where one might look for DebugWindow 2.0?
  7144.  
  7145. >  it's available on Compuserve in the MacDev forum, and on America Online in
  7146. >the Mac Developers area.   It works really nice .. you can also do Hex dumps to
  7147. >the window (ie: DebugHexDump (myBuffer, 1024)) and then print out the window's
  7148. >contents, save as a teachtext document, etc..
  7149. >
  7150. Any idea where we could find it on the Internet? could somebody post it?
  7151.  
  7152. Philippe
  7153. -- 
  7154. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  7155. Philippe Casgrain              Etudiant-Chercheur      Casgrain@ERE.UMontreal.CA
  7156. Departement des Sciences Biologiques                      Universite de Montreal
  7157.                   "Imitation is the sincerest form of flattery"
  7158.  
  7159. +++++++++++++++++++++++++++
  7160.  
  7161. >From kledbetter@aol.com (KLedbetter)
  7162. Date: 27 Feb 1994 01:35:01 -0500
  7163. Organization: America Online, Inc.
  7164.  
  7165. >
  7166. Any idea where we could find it on the Internet? could somebody post it?
  7167.  
  7168. Philippe
  7169. - -------
  7170.  
  7171.   I'm looking into getting it up on the Internet now...I'll post a message as
  7172. soon as I get it out there...
  7173.  
  7174. keith
  7175.  
  7176.  
  7177. +++++++++++++++++++++++++++
  7178.  
  7179. >From tzs@u.washington.edu (Tim Smith)
  7180. Date: 1 Mar 1994 03:24:34 GMT
  7181. Organization: University of Washington School of Law, Class of '95
  7182.  
  7183. In article <2kleqd$51q@unix.sri.com>, Matt Mora <mxmora@unix.sri.com> wrote:
  7184. >He probably twiddled the bits directly. Which is why he said he was using
  7185. >a 5 x 7 character set. He set each bit in the screen's bitmap himself.
  7186. >Cool.
  7187.  
  7188. Actually, I said 3x5.  That way, with one pixel between consecutive characters,
  7189. memory manipulation only had to go down to the nibble level.  On a 640x480
  7190. display, with 2 lines of leading between lines, I could get 160 columns and
  7191. 68 rows.
  7192.  
  7193. In addition to drawing the character, I would also draw an underline three
  7194. lines below the character, and erase the two lines immediately below the
  7195. character.  That way, you could tell which of the 68 rows was the last one
  7196. drawn--it was the one that was underlined.  That way you can tell where you
  7197. are as more than 68 rows are printed and they start to wrap.  I also had an
  7198. end of line marker so you could tell on a row which characters belonged to
  7199. that row, and which were left over from the 68th previous printf, the 136th
  7200. previous printf, etc.
  7201.  
  7202. The hardest part was coming up with a 3x5 'M' that looks different than
  7203. a 3x5 'N'!  Here's my character set, in case anyone is curious.
  7204.  
  7205. struct OneChar
  7206. {
  7207.     char data[5];                           /* the data for a character */
  7208. };
  7209.  
  7210. struct OneChar CharData[] =
  7211. {
  7212.     {5,2,5,2,5},    /* non-existant char */
  7213.     {2,5,7,5,5},    /* 1 A */
  7214.     {6,5,6,5,6},
  7215.     {7,5,4,5,7},
  7216.     {6,5,5,5,6},
  7217.     {7,4,6,4,7},
  7218.     {7,4,6,4,4},
  7219.     {7,4,5,5,7},    /* 7 G */
  7220.     {5,5,7,5,5},
  7221.     {7,2,2,2,7},
  7222.     {3,1,1,5,7},
  7223.     {4,5,6,5,5},
  7224.     {4,4,4,4,7},
  7225.     {5,7,5,5,5},
  7226.     {5,7,7,7,5},
  7227.     {2,5,5,5,2},    /* 15 O */
  7228.     {7,5,7,4,4},
  7229.     {2,5,5,7,3},
  7230.     {6,5,7,6,5},
  7231.     {3,4,6,1,7},
  7232.     {7,2,2,2,2},
  7233.     {5,5,5,5,7},
  7234.     {5,5,5,5,2},
  7235.     {5,5,5,7,5},
  7236.     {5,2,2,2,5},
  7237.     {5,5,2,2,2},
  7238.     {7,1,2,4,7},    /* 26 Z */
  7239.     {3,5,5,5,6},    /* 27 0 */
  7240.     {2,6,2,2,7},
  7241.     {7,5,2,4,7},
  7242.     {7,1,3,1,7},
  7243.     {5,5,7,1,1},
  7244.     {7,4,7,1,7},
  7245.     {4,4,7,5,7},
  7246.     {7,1,1,2,2},
  7247.     {7,5,7,5,7},
  7248.     {7,5,7,1,1},    /* 36 9 */
  7249.     {0,0,0,0,0},    /* 37 space */
  7250.     {2,2,2,0,2},    /* ! */
  7251.     {5,5,0,0,0},    /* " */
  7252.     {5,7,5,7,5},    /* 40 # */
  7253.     {7,6,2,3,7},    /* $ */
  7254.     {3,3,2,6,6},    /* % */
  7255.     {6,5,2,5,7},    /* & */
  7256.     {2,2,0,0,0},    /* ' */
  7257.     {2,4,4,4,2},    /* 45 ( */
  7258.     {2,1,1,1,2},    /* ) */
  7259.     {5,2,7,2,5},    /* * */
  7260.     {0,2,7,2,0},    /* + */
  7261.     {0,0,0,1,3},    /* , */
  7262.     {0,0,7,0,0},    /* 50 - */
  7263.     {0,0,0,6,6},    /* . */
  7264.     {1,1,2,2,4},    /* / */
  7265.     {6,6,0,6,6},    /* : */
  7266.     {6,6,0,2,6},    /* ; */
  7267.     {1,2,4,2,1},    /* 55 < */
  7268.     {0,7,0,7,0},    /* = */
  7269.     {4,2,1,2,4},    /* > */
  7270.     {6,1,2,0,2},    /* ? */
  7271.     {6,4,4,4,6},    /* [ */
  7272.     {4,4,2,2,1},    /* 60 \ */
  7273.     {3,1,1,1,3},    /* ] */
  7274.     {2,5,0,0,0},    /* ^ */
  7275.     {0,0,0,0,7},    /* _ */
  7276.     {4,2,0,0,0},    /* ^ */
  7277.     {3,2,4,2,3},    /* 65 { */
  7278.     {2,2,2,2,2},    /* | */
  7279.     {6,2,1,2,6},    /* } */
  7280.     {4,7,1,0,0},    /* ~ */
  7281.     {0,3,5,6,3},    /* @ */
  7282.     {7,7,7,7,7}     /* end of line marker */
  7283. }
  7284.  
  7285. --Tim Smith
  7286.  
  7287. +++++++++++++++++++++++++++
  7288.  
  7289. >From ez006626@othello.ucdavis.edu (David Xavier Clancy)
  7290. Date: Tue, 1 Mar 1994 09:51:29 GMT
  7291. Organization: University of California, Davis
  7292.  
  7293. I thought the accepted thing was to use FlashMenuBar
  7294.  
  7295. It is not auditory, but if you are looking at the screen, it does the trick.
  7296.  
  7297. Also, I'm pretty sure DebugWindow, (i get the name right?) mentioned in other
  7298. posts is at sumex.  
  7299.  
  7300. --xav
  7301.  
  7302.  
  7303. +++++++++++++++++++++++++++
  7304.  
  7305. >From philip@concave.cs.wits.ac.za (Philip Machanick)
  7306. Date: Tue, 01 Mar 1994 08:51:39 +0200
  7307. Organization: Computer Science Dept, U of Witwatersrand
  7308.  
  7309. In article <lewistotCLtDIA.C3@netcom.com>, lewistot@netcom.com (John Lewis)
  7310. wrote:
  7311.  
  7312. > Surround your dereferences with a LockHandle/UnlockHandle pair. This is
  7313. > not only good programming practice, but it will also solve the problem
  7314. > of SysBeep moving things around.
  7315.  
  7316. No it's not. Much better practice is 
  7317.   oldstate = HGetState(h);
  7318.   HLock(h);
  7319. ...do something assuming h can't move...
  7320.   HSetState(h, oldstate);  
  7321. otherwise you could end up unlocking a handle that the code that called the
  7322. current routine still expects to have locked.
  7323.  
  7324. In any case: there are situations where you don't want to lock a handle and
  7325. to put the locking code in just because you are debugging is not a good
  7326. solution.
  7327. -- 
  7328. Philip Machanick                   philip@concave.cs.wits.ac.za
  7329. Department of Computer Science, University of the Witwatersrand
  7330. 2050 Wits, South Africa
  7331. phone 27(11)716-3309  fax 27(11)339-7965
  7332.  
  7333. +++++++++++++++++++++++++++
  7334.  
  7335. >From walrathw@rferl.org (WalrathW)
  7336. Date: 3 Mar 94 09:22:38 -0500
  7337. Organization: RFE/RL Inc.
  7338.  
  7339. In article <lewistotCLtDIA.C3@netcom.com>
  7340. lewistot@netcom.com (John Lewis) writes:
  7341.  
  7342. > Mahboud Zabetian (mahboud@aggroup.com) wrote:
  7343. > : SysBeep() may move memory and could potentially make dereferenced handles
  7344. > : invalid!
  7345. > You mean you don't lock your handles BEFORE you dereference them?
  7346. > : This is a hard one to chase down, since you now have another bug added to
  7347. > : whatever bug you were originally looking for.
  7348. > Surround your dereferences with a LockHandle/UnlockHandle pair. This is
  7349. > not only good programming practice, but it will also solve the problem
  7350. > of SysBeep moving things around.
  7351. > -- 
  7352.  
  7353. I would disagree that it's good programming practice to just surround
  7354. every handle with HLock/HUnlock calls.  Those calls take time and if
  7355. they aren't absolutely necessary, then you shouldn't use them.
  7356.  
  7357. HLock(myHandle);
  7358. ((MyStruct*)*myHandle)->myLong = 10;
  7359. HUnlock(myHandle);
  7360.  
  7361. nahhh?
  7362.  
  7363.  
  7364. > ---------------------------------------------------------------------------
  7365. > John "I'ld rather be skydiving" Lewis|#include "standard .sig BS" |Witty  |
  7366. > lewistot@netcom.com <- prefered      |Blue Skies to all skydivers.|text   |
  7367. > jlewis@maxis.com    <- work          |USPA 87419, C-22826         |picture|
  7368. > lewistotle@aol.com                   |<Fnord>                     |comming|
  7369.  
  7370. maxis.com, is that the Simulation Games company?
  7371.  
  7372. ______o0o______
  7373.  Wayne Walrath
  7374.  RFE/RL Inc.
  7375.  
  7376. +++++++++++++++++++++++++++
  7377.  
  7378. >From tgreen@ersys.edmonton.ab.ca (Terry Greeniaus)
  7379. Date: Mon, 07 Mar 94 16:13:55 MST
  7380. Organization: Edmonton Remote Systems #2
  7381.  
  7382. > In article <mahboud-230294225858@mahboud.aggroup.com>,
  7383. > Mahboud Zabetian <mahboud@aggroup.com> wrote:
  7384. > >> Wow, good point.  Any suggestions for an easy debugging tool like sysbeep(
  7385.  
  7386. Well, you could use FlashMenuBar(), but I'm not sure whether it messes 
  7387. with memory or not.
  7388.  
  7389. --
  7390. Terry Greeniaus   tgreen@ersys.edmonton.ab.ca   
  7391. Edmonton Remote Systems   Serving Edmonton/Northern Alberta since 1982
  7392.  
  7393. +++++++++++++++++++++++++++
  7394.  
  7395. >From mxmora@unix.sri.com (Matt Mora)
  7396. Date: 10 Mar 1994 09:00:10 -0800
  7397. Organization: SRI International, Menlo Park, CA
  7398.  
  7399. In article <wPBuic1w165w@ersys.edmonton.ab.ca> tgreen@ersys.edmonton.ab.ca (Terry Greeniaus) writes:
  7400. >> In article <mahboud-230294225858@mahboud.aggroup.com>,
  7401. >> Mahboud Zabetian <mahboud@aggroup.com> wrote:
  7402. >
  7403. >Well, you could use FlashMenuBar(), but I'm not sure whether it messes 
  7404. >with memory or not.
  7405.  
  7406. Not unless you are sure the gworld is valid ( ie the one with the menubar)
  7407. before you call it as another poster had mentioned.
  7408.  
  7409.  
  7410. Xavier
  7411.  
  7412.  
  7413.  
  7414. -- 
  7415. ___________________________________________________________
  7416. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  7417. SRI International                       mxmora@unix.sri.com
  7418. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  7419.  
  7420. +++++++++++++++++++++++++++
  7421.  
  7422. >From mbabramo@unix.amherst.edu (MICHAEL BERNARD ABRAMOWICZ)
  7423. Date: 11 Mar 1994 20:15:35 -0500
  7424. Organization: Amherst College, Amherst MA, USA
  7425.  
  7426. > Well, you could use FlashMenuBar(), but I'm not sure whether it messes 
  7427. > with memory or not.
  7428.  
  7429. This is exactly the solution. FlashMenuBar() does NOT move memory.
  7430.  
  7431. > --
  7432. > Terry Greeniaus   tgreen@ersys.edmonton.ab.ca   
  7433. > Edmonton Remote Systems   Serving Edmonton/Northern Alberta since 1982
  7434.  
  7435. Michael Abramowicz
  7436. Amherst College
  7437. Writer, Inside Macintosh: Memory, More Macintosh Toolbox, Sound
  7438.  
  7439. +++++++++++++++++++++++++++
  7440.  
  7441. >From mahboud@aggroup.com (Mahboud Zabetian)
  7442. Date: Sun, 13 Mar 1994 23:34:29 -0800
  7443. Organization: AG Group, Inc.
  7444.  
  7445. In article <2lr53n$lr3@amhux3.amherst.edu>, mbabramo@unix.amherst.edu
  7446. (MICHAEL BERNARD ABRAMOWICZ) wrote:
  7447.  
  7448. > > Well, you could use FlashMenuBar(), but I'm not sure whether it messes 
  7449. > > with memory or not.
  7450. > This is exactly the solution. FlashMenuBar() does NOT move memory.
  7451. > > --
  7452. > > Terry Greeniaus   tgreen@ersys.edmonton.ab.ca   
  7453. > > Edmonton Remote Systems   Serving Edmonton/Northern Alberta since 1982
  7454. > Michael Abramowicz
  7455. > Amherst College
  7456. > Writer, Inside Macintosh: Memory, More Macintosh Toolbox, Sound
  7457.  
  7458. I have tried to use FlashMenuBar in place of SysBeep.  I don't find it as
  7459. useful as SysBeep though.  It is very hard to miss a SysBeep, but
  7460. FlashMenuBar is easy to miss.  Especially if you have a faster machine.
  7461.  
  7462. -mahboud
  7463.  
  7464. - -------------------------------------------------------------
  7465. Mahboud Zabetian
  7466. mahboud@aggroup.com
  7467. ag group, inc.
  7468. 2540 camino diablo, suite 200
  7469. walnut creek, ca 94596
  7470. 510-937-7900 voice
  7471. 510-937-2479 fax
  7472. 510-937-6704 ara
  7473. ftp.aggroup.com anonymous ftp
  7474.  
  7475. +++++++++++++++++++++++++++
  7476.  
  7477. >From Greg_Marriott@genmagic.com (Greg Marriott)
  7478. Date: Mon, 14 Mar 1994 01:55:17 -0800
  7479. Organization: General Magic, Inc.
  7480.  
  7481. mbabramo@unix.amherst.edu (MICHAEL BERNARD ABRAMOWICZ) wrote:
  7482. > > Well, you could use FlashMenuBar(), but I'm not sure whether it messes 
  7483. > > with memory or not.
  7484. > This is exactly the solution. FlashMenuBar() does NOT move memory.
  7485.  
  7486. Wrong.
  7487.  
  7488. This took me less than a minute to check out.  Among the calls made inside
  7489. FlashMenuBar(): NewHandle() and SetHandleSize().
  7490.  
  7491. -- 
  7492. Greg Marriott
  7493. Just Some Guy
  7494. General Magic, Inc.
  7495.  
  7496. Disclaimer: My opinions are not necessarily the same as General Magic's.
  7497.             (can a company even HAVE an opinion?)
  7498.  
  7499. ---------------------------
  7500.  
  7501. >From perlis_a@math.lsu.edu (Alexander Perlis)
  7502. Subject: Improving DrawText speed (Was: Color Terminal Emulator)
  7503. Date: 11 Mar 1994 18:28:27 GMT
  7504. Organization: Louisiana State University InterNetNews Site
  7505.  
  7506. In article <trygve-100394010606@kip-87.apple.com> trygve@apple.com (Trygve  
  7507. Isaacson) writes:
  7508. > 2) Optimize out whitespace: move the pen instead of drawing blanks. Of
  7509. > course, this assumes you can calculate the character width ahead of  
  7510. time,
  7511. > which assumes you're using a monospaced font. Note that boldface throws  
  7512. a
  7513. > wrench in things unless your font's bold maintains the same character  
  7514. width
  7515. > as plain, as does our Noiro font shipped with the SNA ps emulators.
  7516. > Trygve Isaacson
  7517. > SNA ps engineer
  7518. > Apple Computer, Inc.
  7519.  
  7520. I thought the built-in QuickDraw routines for drawing text simply ASSUME  
  7521. that the space character (ASCII 32) in every font is truly a space and  
  7522. simply move the pen without drawing anything when in srcOr mode. Of  
  7523. course, if your font is monospaced and you have a bunch of spaces, it  
  7524. might be faster to just skip over that than letting QuickDraw move the pen  
  7525. a bunch of times, but I don't believe that the speedup is too significant  
  7526. in the sense that one should worry more about speeding up the drawing of  
  7527. actual text than speeding up the movement of the pen over empty regions.
  7528.  
  7529. If you put a graphic character in position 32 of a font, it will NOT be  
  7530. displayed. As far as I can tell, this behavior, and a few other subleties  
  7531. involving graphic characters in the control positions of a font,  
  7532. characters 0 through 31, have never been fully documented or explained by  
  7533. Apple. Please correct me if I'm wrong and point me in the direction of  
  7534. such documentation.
  7535.  
  7536. I got around the problems in QuickDraw by writing a complete replacement  
  7537. for the text drawing system (not too difficult since I only use monospaced  
  7538. fonts in terminal emulation) which can handle fonts of 256 true graphic  
  7539. characters. This solution proved faster than using two Macintosh fonts  
  7540. with 128 characters each to simulate a 256-character font and swapping  
  7541. between the two fonts all the time.
  7542.  
  7543. Incidentally, I never understood WHY QuickDraw has trouble drawing text in  
  7544. srcCopy mode. The only slowdown should come when it has to draw a space,  
  7545. since now it must actually erase the rectangle rather than simply moving  
  7546. the pen. But that should not account for the major difference in speed  
  7547. between srcOr and srcCopy. Can someone at Apple explain this?
  7548.  
  7549. Alexander Perlis
  7550. perlis_a@math.lsu.edu
  7551.  
  7552. ---------------------------
  7553.  
  7554. >From atotic@void.ncsa.uiuc.edu (Alexsander Totic)
  7555. Subject: Interface guidelines for extra program files
  7556. Date: 16 Mar 94 16:36:40 GMT
  7557. Organization: University of Illinois at Urbana
  7558.  
  7559. I am building a program that creates and uses several external files besides
  7560. preferences. I have always disliked any external file approaches, but
  7561. this time I have to store data in this way. I was wandering what the
  7562. Apple's recommendation for storing of these files are: should application
  7563. have its own folder somewhere on a disk, or in a system folder, or spread
  7564. around through user preferences.
  7565.  
  7566. Allowing user to specify location of external folder allows multiple users
  7567. to start up an application by clicking on their preferences file, and have
  7568. everything work fine. But it also confuses them, especially when there are
  7569. many external files.
  7570.  
  7571. There is no right solution, so I would like to skip the responsibility, and
  7572. follow the guidelines.
  7573.  
  7574. Aleks
  7575. -- 
  7576. Aleksandar Totic        -- MacMosaic developer --          atotic@ncsa.uiuc.edu
  7577. Software Development Group      National Center for Supercomputing Applications
  7578.            http://www.ncsa.uiuc.edu/SDG/People/atotic/alex.html
  7579.  
  7580. +++++++++++++++++++++++++++
  7581.  
  7582. >From pcastine@jake.prz.tu-berlin.de (Peter Castine)
  7583. Date: Thu, 17 Mar 1994 20:57:38 GMT
  7584. Organization: PRZ TU-Berlin
  7585.  
  7586. Alexsander Totic writes:
  7587. >I am building a program that creates and uses several external files besides
  7588. >preferences. I have always disliked any external file approaches, but
  7589. >this time I have to store data in this way. I was wandering what the
  7590. >Apple's recommendation for storing of these files are: should application
  7591. >have its own folder somewhere on a disk, or in a system folder, or spread
  7592. >around through user preferences.
  7593. >
  7594. >Allowing user to specify location of external folder allows multiple users
  7595. >to start up an application by clicking on their preferences file, and have
  7596. >everything work fine. But it also confuses them, especially when there are
  7597. >many external files.
  7598. >
  7599. >There is no right solution, so I would like to skip the responsibility, and
  7600. >follow the guidelines.
  7601. >
  7602.  
  7603. The only guideline is "Don't put user files in the same folder as
  7604. the application." This is because the application might well be on
  7605. a file server and the user would probably not have write access to
  7606. that folder. 
  7607.  
  7608. I think the best solution is to do what QuickMail (and several other
  7609. programs) does: instead of a single file in the user's Preferences
  7610. folder, it creates a '<AppName> Stuff' folder in the Preferences
  7611. folder, and dumps everything in there.
  7612.  
  7613. Make sure to use the _FindFolder trap (if it's available) when looking
  7614. for the Prefs folder. It is *NOT* called 'Preferences' on many Macs.
  7615.  
  7616. -- 
  7617. Peter Castine                      | One child is shot every two hours
  7618. pcastine@jake.kgw.tu-berlin.de     | in the U.S.A.
  7619.                    | Thank you for blocking gun control,
  7620.                    | N.R.A.
  7621.  
  7622. ---------------------------
  7623.  
  7624. >From jafl@cco.caltech.edu (John Lindal)
  7625. Subject: Intermixing graphics and text
  7626. Date: 15 Mar 1994 01:35:47 GMT
  7627. Organization: California Institute of Technology, Pasadena
  7628.  
  7629. Has anyone written any straight code or TCL classes that allow pictures
  7630. and text to be intermixed?  Of these, is there anyone willing to share this?
  7631. (or sell it for that matter?)
  7632.  
  7633. Thanks.  John Lindal
  7634.  
  7635.  
  7636. +++++++++++++++++++++++++++
  7637.  
  7638. >From thunderone@delphi.com
  7639. Date: Tue, 15 Mar 94 02:40:05 -0500
  7640. Organization: Delphi (info@delphi.com email, 800-695-4005 voice)
  7641.  
  7642. John Lindal <jafl@cco.caltech.edu> writes:
  7643.  
  7644. >Has anyone written any straight code or TCL classes that allow pictures
  7645. >and text to be intermixed?  Of these, is there anyone willing to share this?
  7646. >(or sell it for that matter?)
  7647.  
  7648. If you want to use TextEdit, it's pretty simple to do.  Here's how I do
  7649. it.  Note that pictHandle is an array containing PICT resources
  7650. (surprise!) and pictPositions is an array that holds the number of the
  7651. character that the lower left corner of the picture is anchored on.
  7652.  
  7653.     Point       tPoint;
  7654.     PicHandle   WhiteNoise;
  7655.     short       i;
  7656.     Rect        theRect;
  7657. /  GrafPtr     old;
  7658.     CGrafPtr    theGraf=(CGrafPtr)theWindow;
  7659.  
  7660.     SetPort(thePort);
  7661.     if(numPicts){
  7662.         for(i=1;i<=numPicts;i++){
  7663.             WhiteNoise=pictHandle[i];
  7664.             if(!WhiteNoise)
  7665.                 return;
  7666.             tPoint=TEGetPoint(pictPositions[i],theTE);
  7667.             HLockHi((Handle)WhiteNoise);
  7668.             theRect=(**WhiteNoise).picFrame;
  7669.  
  7670.             theRect.right=tPoint.h+(theRect.right-theRect.left);
  7671.             theRect.top=tPoint.v-(theRect.bottom-theRect.top);
  7672.             theRect.left=tPoint.h;
  7673.             theRect.bottom=tPoint.v;
  7674.  
  7675.             UQD::KillClip();
  7676.             ClipRect(&teSquare);//(**theTE).viewRect
  7677.  
  7678.             DrawPicture(WhiteNoise,&theRect);
  7679.  
  7680.             if(pictPositions[i]>=(**theTE).selStart&&pictPositions[i]<(**theTE).
  7681. selEnd){
  7682.                 if(UQD::BitDepth()>1){
  7683.                     PenMode(adMin);
  7684.                     RGBForeColor(&(**(GVarHandle)theGraf->grafVars).rgbHiliteCol
  7685. or);
  7686.                     BackColor(blackColor);
  7687.                     PaintRect(&theRect);
  7688.                 }else{
  7689.                     InvertRect(&theRect);
  7690.                 }
  7691.             }
  7692.             ForeColor(blackColor);
  7693.             BackColor(whiteColor);
  7694.             UQD::RestoreClip();
  7695.             HUnlock((Handle)WhiteNoise);
  7696.         }
  7697.     }
  7698.  
  7699. Chris
  7700.  
  7701. -
  7702. Chris Thomas, Delphi ICONtact Developer Database Librarian
  7703. thunderone@delphi.com
  7704.  
  7705. ---------------------------
  7706.  
  7707. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  7708. Subject: Let's kill 24-bit mode! (was Re: Let's kill System 6!)
  7709. Date: 14 Mar 94 18:31:16 +1300
  7710. Organization: University of Waikato, Hamilton, New Zealand
  7711.  
  7712. OK, let's start a new version of this thread, shall we?
  7713.  
  7714. With more and more machines running with more than 8MB of RAM, is it worth
  7715. still testing your code to make sure it works in 24-bit mode? It's so much
  7716. easier leaving out all those StripAddress calls, rather than trying to remember
  7717. when you need them and when you don't, don't you think?
  7718.  
  7719. I've been running a home machine in 32-bit mode for close to 3 years now.
  7720. First it was an LC with 10MB, now it's a C650 with 16MB. And Godot, my long-
  7721. awaited, brand-spanking-new 840AV at work, couldn't run in 24-bit mode if I
  7722. wanted it to.
  7723.  
  7724. So what do other people think? Is it time to declare 24-bit mode dead yet...?
  7725.  
  7726. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  7727. Info & Tech Services Division              fax: +64-7-838-4066
  7728. University of Waikato            electric mail: ldo@waikato.ac.nz
  7729. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  7730.  
  7731. +++++++++++++++++++++++++++
  7732.  
  7733. >From jwbaxter@olympus.net (John W. Baxter)
  7734. Date: Mon, 14 Mar 1994 09:18:43 -0800
  7735. Organization: Internet for the Olympic Peninsula
  7736.  
  7737. In article <1994Mar14.183116.26366@waikato.ac.nz>, ldo@waikato.ac.nz
  7738. (Lawrence D'Oliveiro, Waikato University) wrote:
  7739.  
  7740. > So what do other people think? Is it time to declare 24-bit mode dead yet...?
  7741.  
  7742. If you like, and test for the machine being in 24-bit mode at the start of
  7743. your code, and alert and exit gracefully.  I don't mind being told gently
  7744. that your code won't work on my secondary machine (a 4 meg Mac Plus).  I do
  7745. mind if it crashes.  And I mind a WHOLE LOT if it corrupts the disk
  7746. while/before crashing, or (worse) corrupts the disk without crashing.
  7747.  
  7748. Same with my primary machine, in the once-every-6-months situation where I
  7749. set it to 24-bit mode for some odd reason.
  7750.  
  7751. With some of the newest machines not being able to run in 24-bit mode, the
  7752. time is approaching, but it may not be here yet.
  7753. -- 
  7754. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  7755.    jwbaxter@pt.olympus.net
  7756.  
  7757. +++++++++++++++++++++++++++
  7758.  
  7759. >From u9119523@sys.uea.ac.uk (Graham Cox)
  7760. Date: Tue, 15 Mar 1994 17:41:52 GMT
  7761. Organization: School of Information Systems, UEA, Norwich
  7762.  
  7763. In article <1994Mar14.183116.26366@waikato.ac.nz>, ldo@waikato.ac.nz
  7764. (Lawrence D'Oliveiro, Waikato University) wrote:
  7765.  
  7766. > OK, let's start a new version of this thread, shall we?
  7767. > With more and more machines running with more than 8MB of RAM, is it worth
  7768. > still testing your code to make sure it works in 24-bit mode? It's so much
  7769. > easier leaving out all those StripAddress calls, rather than trying to remember
  7770. > when you need them and when you don't, don't you think?
  7771. > I've been running a home machine in 32-bit mode for close to 3 years now.
  7772. > First it was an LC with 10MB, now it's a C650 with 16MB. And Godot, my long-
  7773. > awaited, brand-spanking-new 840AV at work, couldn't run in 24-bit mode if I
  7774. > wanted it to.
  7775. > So what do other people think? Is it time to declare 24-bit mode dead yet...?
  7776. > Lawrence D'Oliveiro                       fone: +64-7-856-2889
  7777. > Info & Tech Services Division              fax: +64-7-838-4066
  7778. > University of Waikato            electric mail: ldo@waikato.ac.nz
  7779. > Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  7780.  
  7781.  
  7782. Am I missing something vital here? I have never used StripAddress in any
  7783. program I've ever written and they all work in 24 or 32-bit mode. Either
  7784. what I'm doing is not very advanced compared to yours or you aren't doing
  7785. things the compatible way! I don't want to dump on you about this without
  7786. knowing the facts- I therefore assume the former (?). I believe that
  7787. addresses/pointers are always valid in whatever mode and OF COURSE you
  7788. never try to set the high byte of a handle right?
  7789.  
  7790.  
  7791.  
  7792. - ------------------------------------------------------------------------
  7793. Love & BSWK, Graham
  7794.  
  7795. -Everyone is entitled to their opinion, no matter how wrong they may be...
  7796. - ------------------------------------------------------------------------
  7797.  
  7798. +++++++++++++++++++++++++++
  7799.  
  7800. >From t-gaul@i-link.com (Troy Gaul)
  7801. Date: Tue, 15 Mar 1994 17:10:35 -0600
  7802. Organization: I-Link, Ltd.
  7803.  
  7804. In article <u9119523-150394174152@case6.sys.uea.ac.uk>,
  7805. u9119523@sys.uea.ac.uk (Graham Cox) wrote:
  7806.  
  7807. > In article <1994Mar14.183116.26366@waikato.ac.nz>, ldo@waikato.ac.nz
  7808. > (Lawrence D'Oliveiro, Waikato University) wrote:
  7809. > > OK, let's start a new version of this thread, shall we?
  7810. > > 
  7811. > > With more and more machines running with more than 8MB of RAM, is it worth
  7812. > > still testing your code to make sure it works in 24-bit mode? It's so much
  7813. > > easier leaving out all those StripAddress calls, rather than trying to remember
  7814. > > when you need them and when you don't, don't you think?
  7815. > > 
  7816. > > I've been running a home machine in 32-bit mode for close to 3 years now.
  7817. > > First it was an LC with 10MB, now it's a C650 with 16MB. And Godot, my long-
  7818. > > awaited, brand-spanking-new 840AV at work, couldn't run in 24-bit mode if I
  7819. > > wanted it to.
  7820. > > 
  7821. > > So what do other people think? Is it time to declare 24-bit mode dead yet...?
  7822. > Am I missing something vital here? I have never used StripAddress in any
  7823. > program I've ever written and they all work in 24 or 32-bit mode. Either
  7824. > what I'm doing is not very advanced compared to yours or you aren't doing
  7825. > things the compatible way! I don't want to dump on you about this without
  7826. > knowing the facts- I therefore assume the former (?). I believe that
  7827. > addresses/pointers are always valid in whatever mode and OF COURSE you
  7828. > never try to set the high byte of a handle right?
  7829.  
  7830. There are cases where you must call StripAddress for a program to function
  7831. correctly in all 'modes'. It is possible that you haven't run across them.
  7832.  
  7833. One case in point is when you are manually switching the processor's
  7834. addressing modes (like, when working with directly accessing data in a
  7835. GWorld PixMap).  Since the PixMap may be stored on a NuBus board's memory
  7836. (our of 24-bit range), you should switch to 32-bit mode to access the data
  7837. (and back when you're done).  If you have a pointer in a local variable
  7838. from before you switched out of 24-bit, it is possible this pointer has
  7839. some high bits being used, so you should strip it if you intend to
  7840. dereference it from 32-bit mode.
  7841.  
  7842. Moral is: when you might be changing modes, you should be careful.
  7843.  
  7844. Or something like that. :)
  7845.  
  7846. _troy
  7847. //////// //////___Troy Gaul_________________________t-gaul@i-link.com__ //
  7848.   //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
  7849.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
  7850. //    //////________________________________________________________ //
  7851. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  7852. Subject: Let's kill 24-bit mode! (was Re: Let's kill System 6!)
  7853. Date: Tue, 15 Mar 1994 23:47:30 GMT
  7854. Organization: Proteus Ventures, Inc.
  7855.  
  7856. In article <1994Mar14.183116.26366@waikato.ac.nz>
  7857. ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
  7858.  
  7859. > With more and more machines running with more than 8MB of RAM, is it worth
  7860. > still testing your code to make sure it works in 24-bit mode? It's so much
  7861. > easier leaving out all those StripAddress calls, rather than trying to remember
  7862. > when you need them and when you don't, don't you think?
  7863.  
  7864. Huh? StripAddress? What's that? :-) :-)
  7865.  
  7866. Juan Ingles
  7867. <DACRXL01.OURX124@tcp30.dx.deere.com>
  7868. --
  7869. Proteus Ventures, Inc. - Computer Software Consulting and Development
  7870.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  7871.  
  7872. +++++++++++++++++++++++++++
  7873.  
  7874. >From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
  7875. Date: Wed, 16 Mar 94 00:15:54 GMT
  7876. Organization: Network Analysis Ltd
  7877.  
  7878.  
  7879. In article <u9119523-150394174152@case6.sys.uea.ac.uk> (comp.sys.mac.programmer), u9119523@sys.uea.ac.uk (Graham Cox) writes:
  7880.  
  7881. > ... I believe that
  7882. > addresses/pointers are always valid in whatever mode and OF COURSE you
  7883. > never try to set the high byte of a handle right?
  7884.  
  7885. You don't have to: the resource manager will happily set them for you,
  7886. for example. Most of the time it doesn't matter, but there are times
  7887. when it does (like when you call a code resource loaded with the RM and
  7888. the CR turns on 32-bit mode - your return addreses on the stack become
  7889. instant garbage). There's a tech note that tells you when StripAdress
  7890. is necessary; can't remember what it's called off the top of my head.
  7891.  
  7892. Sak Wathanasin
  7893. Network Analysis Limited
  7894. 178 Wainbody Ave South, Coventry CV3 6BX, UK
  7895.  
  7896. Internet: sw@network-analysis-ltd.co.uk 
  7897. uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
  7898. Phone: (+44) 203 419996 Mobile:(+44) 850 587411  Fax: (+44) 203 690690
  7899.  
  7900. ---------------------------
  7901.  
  7902. >From bsc@oui.com (Bill Stewart-Cole)
  7903. Subject: Let's kill system 6!
  7904. Date: 20 Feb 1994 13:12:15 -0600
  7905. Organization: Odyssey Ultraware Inc
  7906. St Louis, MO
  7907.  
  7908. The whole discussion on supporting system 6 has spurred some thoughts: 
  7909.  
  7910. Would not Mac developers benefit by a 100% move to system 7?
  7911. Would not Mac users benefit by upgrading to 7 and Macs that can run it well?
  7912.  
  7913. It is a royal pain to support BOTH the full features of 7, and system 6.  I
  7914. have taken 2 tracks: 1. if the program specifically calls for features of 7,
  7915. I check for it and politely quit if I don't have it. 2. If the program can be
  7916. used just fine without 7-specific features, I use all the system 6 versions
  7917. and let the program crash on the rare 512k (not 512ke) running 4.1.   The one
  7918. time I tried to develop a program for an either/or operation, the result was
  7919. a confusing program to debug and a program far too big. And a nervous tic:). 
  7920.   We'd all make smaller, clearer, and less bug-prone code if we stuck to one
  7921. set of system features.  Programs would get out faster. Money would flow in
  7922. for programs sooner.  We'd have fewer ulcers.
  7923.  
  7924. On the user side, it's important to consider who is still using system 6 and
  7925. why.  They are essentially 2 types: 1. People who have a fixed function for
  7926. their Mac that works well and can be done with 6.  2. People who  would do
  7927. better running 7 on a faster Mac.   In the first group, they aren't buying
  7928. software.  In the second,  they are ready to move to 7 with the slightest
  7929. nudge. A //ci-class Mac is a fine platform for 7, and the 5 machines in that
  7930. general performance range are breaking below $700 on the used market.  Even
  7931. if Joe Plus User won't bite on a $2000 PDM PowerMac, he is not unlikely to
  7932. see the used //ci's and //cx's and LC3's being dumped to upgrade by other
  7933. users who want faster boxes as tempting.  The increased pressure in that
  7934. direction of 7-only software (i.e. requiring a good machine for running 7)
  7935. will make for a user base with more compatibility, more power, and less
  7936. ghettoizing of users. 
  7937.  
  7938. Anyway, I think it is a positive step for developers to move away from
  7939. supporting system 6 because of the good it will do to get everyone running 7,
  7940. both for developers and for users. 
  7941.  
  7942. +++++++++++++++++++++++++++
  7943.  
  7944. >From rrwood@r-node.io.org (Roy Wood)
  7945. Date: 21 Feb 1994 10:41:47 -0500
  7946. Organization: Internex Online (io.org) Data: 416-363-3783  Voice: 416-363-8676
  7947.  
  7948.  
  7949. Another group of users stuck with sloooooooow system 6 machines are students
  7950. and teachers at public schools.  I'd love to upgrade our lab to faster
  7951. machines, but there's no way our budget can afford it.
  7952.  
  7953. This is not such a huge problem, in terms of the thread being discussed,
  7954. since we're doing mostly word processing and other mundane things, and
  7955. we're hardly likely to rush out and invest in any bleeding-edge killer
  7956. apps anyway.
  7957.  
  7958. -Roy
  7959.  
  7960.  
  7961. +++++++++++++++++++++++++++
  7962.  
  7963. >From time@garnet.msen.com (Tim Endres)
  7964. Date: 22 Feb 1994 17:32:28 GMT
  7965. Organization: Msen, Inc. -- Ann Arbor, MI (account info: +1 313 998-4562)
  7966.  
  7967. Bill Stewart-Cole (bsc@oui.com) wrote:
  7968. : The whole discussion on supporting system 6 has spurred some thoughts: 
  7969.  
  7970. : Would not Mac developers benefit by a 100% move to system 7?
  7971. : Would not Mac users benefit by upgrading to 7 and Macs that can run it well?
  7972.  
  7973. This is a marketing decision, not a engineering decision.
  7974. Perform your own market analysis and make a business decision.
  7975. That is what most developers do...
  7976.  
  7977. +++++++++++++++++++++++++++
  7978.  
  7979. >From wbostow@hounix.org (Wayne Bostow)
  7980. Date: Thu, 24 Feb 1994 15:09:52 GMT
  7981. Organization: Houston UNIX Users Group (HOUNIX), Houston, TX
  7982.  
  7983.  
  7984. : Would not Mac developers benefit by a 100% move to system 7?
  7985.  
  7986.   Well, not me! I am ticked at Apple for allowing no upgrade path from
  7987. MPW 1.0. I bought everything in '87 for under $300. I did not get several
  7988. upgrades because APPLE said not to unless you had a machine to handle
  7989. it. My current version will not even launch under sys 7. To get everything
  7990. now is about $1000 plus a new hard drive and more memory. 
  7991.  
  7992.   As an assembly programmer, I see most of the improvements as clutter.
  7993. -- 
  7994. __________________________________________________________
  7995.   Wayne Bostow "The HangulMan"
  7996.    10558 Alcott, Houston, TX 77043    ph. (713)468-6546
  7997.      wbostow@hounix.org
  7998.  
  7999. +++++++++++++++++++++++++++
  8000.  
  8001. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  8002. Date: Fri, 25 Feb 1994 11:04:37 GMT
  8003. Organization: (none)
  8004.  
  8005. time@garnet.msen.com (Tim Endres) writes:
  8006.  
  8007. >Bill Stewart-Cole (bsc@oui.com) wrote:
  8008. >: The whole discussion on supporting system 6 has spurred some thoughts: 
  8009.  
  8010. >: Would not Mac developers benefit by a 100% move to system 7?
  8011. >: Would not Mac users benefit by upgrading to 7 and Macs that can run it well?
  8012.  
  8013. That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8014. Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8015. All those Macs are significantly nicer with System 6. Apple has designed
  8016. System 7 in a way that makes a 100% move to System 7 *impossible*. System
  8017. 6 won't go away until the last of the above Macs stop working. Sure, many
  8018. users will move to sys 7 even with slow Macs, usually since they are forced
  8019. to, but lots of them will run system 6 until they die.
  8020.  
  8021. And they won't die for a long time yet. You might be able to get rid of
  8022. some by good trade-in offers, but even that won't help. Would you trade an
  8023. SE for a LC475 at half the price? Sure? Many people will say yes, but some
  8024. may think twice. Some of those Macs - especially SE - are *much* more
  8025. reliable than the new ones. That's (one of the reasons) why they were
  8026. so expensive.
  8027.  
  8028. >This is a marketing decision, not a engineering decision.
  8029. >Perform your own market analysis and make a business decision.
  8030. >That is what most developers do...
  8031.  
  8032. Isn't this both marketing and engineering?
  8033.  
  8034. --
  8035. - -
  8036. Ingemar Ragnemalm, PhD
  8037. Image processing, Mac shareware games
  8038. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  8039.  
  8040. +++++++++++++++++++++++++++
  8041.  
  8042. >From j-norstad@nwu.edu (John Norstad)
  8043. Date: Fri, 25 Feb 1994 13:28:09 -0600
  8044. Organization: Northwestern University
  8045.  
  8046. In article <CLs1Fr.Fup@lysator.liu.se>, ingemar@lysator.liu.se (Ingemar
  8047. Ragnemalm) wrote:
  8048.  
  8049. > That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8050. > Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8051. > All those Macs are significantly nicer with System 6.
  8052.  
  8053. I couldn't disagree more strongly. I have a Mac Classic at home with 4
  8054. megs. It is *infinitely* nicer with System 7 than with System 6. My two
  8055. kids, ages 8 and 13, who use it for homework, agree with me 100%.
  8056.  
  8057. You need a Mac Plus or later with at least 4 megs to run System 7. It
  8058. works just fine on the old Macs, and is nicer than System 6 on those Macs
  8059. for exactly the same reason that it's nicer than System 6 on the newer and
  8060. bigger Macs.
  8061.  
  8062. At NU, we have completely dropped support for System 6. We tell people to
  8063. get at least 4 megs and run System 7 on their old Macs. They can stay with
  8064. System 6 if they wish, but if they do they are on their own, with no
  8065. support from us. This was a good decision, IMHO.
  8066.  
  8067. -- 
  8068. John Norstad
  8069. Academic Computing and Network Services
  8070. Northwestern University
  8071. j-norstad@nwu.edu
  8072.  
  8073. +++++++++++++++++++++++++++
  8074.  
  8075. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  8076. Date: Fri, 25 Feb 1994 19:31:46 GMT
  8077. Organization: Proteus Ventures, Inc.
  8078.  
  8079. In article <CLs1Fr.Fup@lysator.liu.se>
  8080. ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  8081.  
  8082. > Some of those Macs - especially SE - are *much* more
  8083. > reliable than the new ones. That's (one of the reasons) why they were
  8084. > so expensive.
  8085.  
  8086. Huh? Is there any evidence to support this? In my personal dealings, I
  8087. have found newer machines more reliable.
  8088.  
  8089. >That's (one of the reasons) why they were so expensive.
  8090.  
  8091. If that were true, they would still hold a high value. I would think
  8092. that  profit margins, R&D, and inflation make up 99% of the reason.
  8093.  
  8094. Juan Ingles
  8095. <DACRXL01.OURX124@tcp30.dx.deere.com>
  8096. --
  8097. Proteus Ventures, Inc. - Computer Software Consulting and Development
  8098.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  8099. -- 
  8100. All reality portrayed in this message is fictional. Any resemblance to
  8101. any real reality, alive or dead, is purely coincidental and
  8102. unintentional.
  8103.  
  8104. +++++++++++++++++++++++++++
  8105.  
  8106. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  8107. Date: 25 Feb 1994 22:08:30 GMT
  8108. Organization: Royal Institute of Technology, Stockholm, Sweden
  8109.  
  8110. In <CLs1Fr.Fup@lysator.liu.se> ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  8111.  
  8112. >That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8113. >Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8114.  
  8115. My value judgement is that all of the color-capable Macs are
  8116. also System-7-capable.
  8117.  
  8118. >All those Macs are significantly nicer with System 6. Apple has designed
  8119. >System 7 in a way that makes a 100% move to System 7 *impossible*. System
  8120.  
  8121. "All those Macs"
  8122.  
  8123. Apple is increasing its market share som 30% a year, and all macs sold
  8124. the last few years have been System 7 Macs. System 6 will go away, not
  8125. only because people upgrade, but because Apple sells so many more macs
  8126. a year now than in 1991.
  8127.  
  8128. Cheers,
  8129.  
  8130.                     / h+
  8131. -- 
  8132.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  8133.  
  8134.    This article printed on 100% recycled electrons.
  8135.  
  8136. +++++++++++++++++++++++++++
  8137.  
  8138. >From cabu1hj@ube.ub.umd.edu
  8139. Date: 26 Feb 94 22:52:01 -0500
  8140. Organization: University of Baltimore
  8141.  
  8142. In article <CLs1Fr.Fup@lysator.liu.se>, ingemar@lysator.liu.se 
  8143. (Ingemar Ragnemalm) writes:
  8144. > [stuff deleted]
  8145. > That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8146. > Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8147. > All those Macs are significantly nicer with System 6. 
  8148.  
  8149. I think you need to double check statements like this.  Several of these
  8150. systems run just fine with System 7.0, 7.0.1, & 7.1.  Not with the 
  8151. factory shipped memory (like 3MB on the IIsi).  Running them with 
  8152. 8MB+ isn't unrealistic given the size of current applications either.
  8153.  
  8154.  
  8155. +++++++++++++++++++++++++++
  8156.  
  8157. >From qsi@NU91.wlink.nl (Peter Kocourek)
  8158. Date: Sun, 27 Feb 1994 00:22:45 +0100
  8159. Organization: (none)
  8160.  
  8161. Ingemar Ragnemalm wrote in a message on 25 Feb 94
  8162.  
  8163.  IR> That means killing off all Macs below LC III. Plus, SE, LC, 
  8164.  IR> LC II, Classic, Classic II, Color Classic, PB100,Portable, 
  8165.  IR> perhaps even IIcx, IIsi and IIvi. All those Macs are significantly 
  8166.  IR> nicer with System 6. Apple has designed System 7 in a way that 
  8167.  
  8168. I beg to differ. I have a IIsi here, and I don't see how running System 6 on it
  8169. would make it "nicer". I'd lose aliases, drag & drop, AppleEvents (and hence
  8170. AppleScript), a much better Finder, WorldScript, and Publish & Subscribe. How
  8171. can the loss of these make the machine "nicer"?
  8172.  
  8173.  IR> makes a 100% move to System 7 *impossible*. System 6 won't 
  8174.  IR> go away until the last of the above Macs stop working. Sure, 
  8175.  IR> many users will move to sys 7 even with slow Macs, usually 
  8176.  IR> since they are forced to, but lots of them will run system 
  8177.  IR> 6 until they die. 
  8178.  
  8179. Oh, sure, a 100% adoption rate for System 7 won't ever happen; after all, there
  8180. are still people running CP/M too. :-) But I think you are wrong with your
  8181. classification of System 6 Macs; I don't know anybody running System 6 on an LC
  8182. or Mac II. And System 6 is dying very quickly, now that Apple is selling huge
  8183. amounts of Macs every year (perhaps as many as 4 million this year), none of
  8184. which can run System 6.
  8185.  
  8186.  IR> And they won't die for a long time yet. You might be able to 
  8187.  IR> get rid of some by good trade-in offers, but even that won't 
  8188.  IR> help. Would you trade an SE for a LC475 at half the price? 
  8189.  IR> Sure? Many people will say yes, but some may think twice. Some 
  8190.  IR> of those Macs - especially SE - are *much* more reliable than 
  8191.  IR> the new ones. That's (one of the reasons) why they were so 
  8192.  IR> expensive.
  8193.  
  8194. I'm extremely skeptical about this claim. Could you provide some evidence to
  8195. support this? The reason they were so expensive was because Apple had huge
  8196. profit margins.
  8197.  
  8198.  
  8199. YHS:QSI!
  8200.  
  8201.  
  8202. +++++++++++++++++++++++++++
  8203.  
  8204. >From isis@netcom.com (Mike Cohen)
  8205. Date: Sun, 27 Feb 1994 20:27:17 GMT
  8206. Organization: ISIS International
  8207.  
  8208. cabu1hj@ube.ub.umd.edu writes:
  8209.  
  8210. >In article <CLs1Fr.Fup@lysator.liu.se>, ingemar@lysator.liu.se 
  8211. >(Ingemar Ragnemalm) writes:
  8212. >> 
  8213. >> [stuff deleted]
  8214. >> 
  8215. >> That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8216. >> Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8217. >> All those Macs are significantly nicer with System 6. 
  8218.  
  8219. >I think you need to double check statements like this.  Several of these
  8220. >systems run just fine with System 7.0, 7.0.1, & 7.1.  Not with the 
  8221. >factory shipped memory (like 3MB on the IIsi).  Running them with 
  8222. >8MB+ isn't unrealistic given the size of current applications either.
  8223.  
  8224. I have a PB100, IIsi (with 14 megs of RAM & a FPU) and an SE/30 (acting as a
  8225. file server). All of them run System 7 or later (S7Pro on the IIsi) and I
  8226. don't think I could live with anything less. System 6 should finally be laid
  8227. to rest. The speed & size difference isn't that great (the lean system on my
  8228. PB even though I have CPU, FaxPro, & ARA is only 1300K) and the many benefits
  8229. & convenience features of System 7 far outweigh the tiny speed difference.
  8230. -- 
  8231. Mike Cohen - isis@netcom.com
  8232. NewtonMail: MikeC49506 / ALink: D6734 / AOL: MikeC20
  8233.  
  8234.  
  8235. +++++++++++++++++++++++++++
  8236.  
  8237. >From L.H.Wood@lut.ac.uk
  8238. Date: Sun, 27 Feb 1994 22:56:15 GMT
  8239. Organization: Loughborough University, UK.
  8240.  
  8241. In article <762314409.AA03366@nu91.wlink.nl> qsi@NU91.wlink.nl (Peter Kocourek) writes:
  8242. >Ingemar Ragnemalm wrote in a message on 25 Feb 94
  8243. >
  8244. > IR> That means killing off all Macs below LC III. Plus, SE, LC, 
  8245. > IR> LC II, Classic, Classic II, Color Classic, PB100,Portable, 
  8246. > IR> perhaps even IIcx, IIsi and IIvi. All those Macs are significantly 
  8247. > IR> nicer with System 6. Apple has designed System 7 in a way that 
  8248. >
  8249. >I beg to differ. I have a IIsi here, and I don't see how running System 6 on it
  8250. >would make it "nicer". I'd lose aliases, drag & drop, AppleEvents (and hence
  8251. >AppleScript), a much better Finder, WorldScript, and Publish & Subscribe. How
  8252. >can the loss of these make the machine "nicer"?
  8253. >
  8254. System 6 and 7 store things at the opposite ends of memory to each other.
  8255. Under S6 on a IIsi, a large disk cache is not required to boost drawing-to
  8256. video speeds. Nothing gets put in the remaining part of that megabyte until
  8257. you fill the machine right up.
  8258.  
  8259. Considering that the disk cache in not used under S6 Multifinder, this is
  8260. a blessing twice over. (Aside: I've read that Apple are redoing the disk-cache
  8261. code. Can we expect a disk cache whose size you don't set, that utilises free
  8262. memory wherever it can, a la Windows NT, for System 7.5?)
  8263.  
  8264. L.
  8265.  
  8266. +++++++++++++++++++++++++++
  8267.  
  8268. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  8269. Date: 28 Feb 94 17:26:34
  8270. Organization: Integrated Systems Laboratory, ETH, Zurich
  8271.  
  8272. In article <CLs1Fr.Fup@lysator.liu.se>, ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  8273.  
  8274. > time@garnet.msen.com (Tim Endres) writes:
  8275.  
  8276. >>Bill Stewart-Cole (bsc@oui.com) wrote:
  8277. >>: The whole discussion on supporting system 6 has spurred some thoughts: 
  8278.  
  8279. >>: Would not Mac developers benefit by a 100% move to system 7?
  8280. >>: Would not Mac users benefit by upgrading to 7 and Macs that can run it well?
  8281.  
  8282. > That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8283. > Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8284. > All those Macs are significantly nicer with System 6.
  8285.  
  8286. I do most of my programming on an original Mac II. For about a year, I had one
  8287. System 6 and one System 7 startup volume, but it turned out taht I never used
  8288. the System 6 volume anymore.
  8289.  
  8290. Matthias
  8291.  
  8292. - ---
  8293. Matthias Neeracher                                      neeri@iis.ee.ethz.ch
  8294.    "I feel morally and intellectually obligated simply to concede that the 
  8295.     death penalty experiment has failed." 
  8296.                                -- Supreme Court Justice Harry A. Blackmun
  8297.  
  8298. +++++++++++++++++++++++++++
  8299.  
  8300. >From wbostow@hounix.org (Wayne Bostow)
  8301. Date: Mon, 28 Feb 1994 21:39:45 GMT
  8302. Organization: Houston UNIX Users Group (HOUNIX), Houston, TX
  8303.  
  8304.  
  8305. >If that were true, they would still hold a high value. I would think
  8306. that  profit margins, R&D, and inflation make up 99% of the reason.
  8307.  
  8308.   I think the used price lists show SE30s higher that Classic IIs and
  8309. IIcx's higher than their LC replacements. I attribute it to people who
  8310. want to continue using 6.
  8311.  
  8312.   There are lots of us not ready to spend thousands on hardware and
  8313. software upgrades even to get something " *infinitely* nicer".
  8314.  
  8315.  
  8316.  
  8317.  
  8318. -- 
  8319. __________________________________________________________
  8320.   Wayne Bostow "The HangulMan"
  8321.    10558 Alcott, Houston, TX 77043    ph. (713)468-6546
  8322.      wbostow@hounix.org
  8323.  
  8324. +++++++++++++++++++++++++++
  8325.  
  8326. >From gdl@stlawrence.maths (Mr_G._Landweber_student_tel_2-73550)
  8327. Date: 28 Feb 1994 23:48:12 GMT
  8328. Organization: (none)
  8329.  
  8330.    In article <CLs1Fr.Fup@lysator.liu.se>
  8331.    ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  8332.  
  8333.    > Some of those Macs - especially SE - are *much* more
  8334.    > reliable than the new ones. That's (one of the reasons) why they were
  8335.    > so expensive.
  8336.  
  8337. I remember writing a 3-page essay with WriteNow on my old Mac SE, and
  8338. it crashed at least three times.  More recently, I wrote a 50+ page
  8339. thesis with Word and it only crashed once.
  8340.  
  8341. In my experience, my Mac IIcx/Rocket is much more stable than my SE
  8342. ever was.  In fact, most of my crashes come from bugs in pre-release
  8343. versions of Greg's Buttons (some pretty spectatular things happen when
  8344. you patch _GetResource and trash A1).
  8345.  
  8346. -- Greg "Buttons" Landweber
  8347.    gdl@maths.ox.ac.uk
  8348.  
  8349. +++++++++++++++++++++++++++
  8350.  
  8351. >From cabu1hj@ube.ub.umd.edu
  8352. Date: 28 Feb 94 19:53:09 -0500
  8353. Organization: University of Baltimore
  8354.  
  8355. In article <WISEKB.12.0016AE3C@caedm.et.byu.edu>, 
  8356. WISEKB@caedm.et.byu.edu (Kevin B. Wise) writes:
  8357. > Long live system 6!!!!!!!!!
  8358.  
  8359. Spoken like a ture horse & buggy man.
  8360.  
  8361.  
  8362. +++++++++++++++++++++++++++
  8363.  
  8364. >From jwbaxter@olympus.net (John W. Baxter)
  8365. Date: Tue, 01 Mar 1994 08:48:30 -0800
  8366. Organization: Internet for the Olympic Peninsula
  8367.  
  8368. I don't want to prevent anyone from using System 6 who wants to do so.
  8369.  
  8370. On the other hand, I haven't written anything for System 6 for a couple of
  8371. years.  I've forgotten how.  I don't want to relearn.  So...what I write
  8372. won't do any good for people who run System 6.  [But...I haven't released
  8373. anything major recently, anyhow.]
  8374.  
  8375. For some developers, there's still a nice market of System 6 users.  Go for
  8376. it!
  8377.  
  8378. -- 
  8379. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  8380.    jwbaxter@pt.olympus.net
  8381.  
  8382. +++++++++++++++++++++++++++
  8383.  
  8384. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  8385. Date: 1 Mar 1994 19:42:48 GMT
  8386. Organization: Royal Institute of Technology, Stockholm, Sweden
  8387.  
  8388. In <1994Feb28.213945.20363@hounix.org> wbostow@hounix.org (Wayne Bostow) writes:
  8389.  
  8390. >  I think the used price lists show SE30s higher that Classic IIs and
  8391. >IIcx's higher than their LC replacements. I attribute it to people who
  8392. >want to continue using 6.
  8393.  
  8394. I attribute it to an informed market; the SE30 is twice the speed
  8395. of the Classic II and can take more memory; the IIcx is not only twice
  8396. the speed of the LC, it also has three NuBus slots.
  8397.  
  8398. Cheers,
  8399.  
  8400.                         / h+
  8401. -- 
  8402.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  8403.  "Don't use the Layer Manager"
  8404.  
  8405. +++++++++++++++++++++++++++
  8406.  
  8407. >From temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple)
  8408. Date: Wed, 2 Mar 1994 20:11:17 GMT
  8409. Organization: Naval Research Laboratory
  8410.  
  8411. In article <2l05ro$mqi@news.kth.se>
  8412. d88-jwa@mumrik.nada.kth.se (Jon W‰tte) writes:
  8413.  
  8414. > In <1994Feb28.213945.20363@hounix.org> wbostow@hounix.org (Wayne Bostow) writes:
  8415. > >  I think the used price lists show SE30s higher that Classic IIs and
  8416. > >IIcx's higher than their LC replacements. I attribute it to people who
  8417. > >want to continue using 6.
  8418. > I attribute it to an informed market; the SE30 is twice the speed
  8419. > of the Classic II and can take more memory; the IIcx is not only twice
  8420. > the speed of the LC, it also has three NuBus slots.
  8421.  
  8422. Agreed. Moreover, the SE/30 and IIcx were quality machines. Designed
  8423. well and made to last. The LCs and Classic IIs always feel cheap in
  8424. comparison, with much less care taken in their design and manufacture. 
  8425. Not that I would turn my nose up at a LC475 (Q605)...
  8426.  
  8427. Jon
  8428.  
  8429. +++++++++++++++++++++++++++
  8430.  
  8431. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  8432. Date: Wed, 2 Mar 1994 19:29:08 GMT
  8433. Organization: (none)
  8434.  
  8435. cabu1hj@ube.ub.umd.edu writes:
  8436.  
  8437. >In article <CLs1Fr.Fup@lysator.liu.se>, ingemar@lysator.liu.se 
  8438. >(Ingemar Ragnemalm) writes:
  8439. >> 
  8440. >> [stuff deleted]
  8441. >> 
  8442. >> That means killing off all Macs below LC III. Plus, SE, LC, LC II, Classic,
  8443. >> Classic II, Color Classic, PB100,Portable, perhaps even IIcx, IIsi and IIvi.
  8444. >> All those Macs are significantly nicer with System 6. 
  8445.  
  8446. >I think you need to double check statements like this.  Several of these
  8447. >systems run just fine with System 7.0, 7.0.1, & 7.1.  Not with the 
  8448. >factory shipped memory (like 3MB on the IIsi).  Running them with 
  8449. >8MB+ isn't unrealistic given the size of current applications either.
  8450.  
  8451. I didn't say it won't work - it will, at least with 4 megs. I said that
  8452. those Macs are so slow that they are *noticeably* more sluggish (at least
  8453. in the Finder) when using System 7, and therefore many users won't change.
  8454. And as long as many users have a better life with the *old* system, it
  8455. won't go away in a long time.
  8456.  
  8457. I've tried Sys 7 on my SE. Never again. I use System 7 on my LC. I wish
  8458. I didn't have to, but with sys 6 it can't print due to the sys 7-running
  8459. IIfx that uses the same printer. When I switch the LC to sys 6 (I have both
  8460. on it, on separate disks) it feels like if I had plugged in an accelerator
  8461. board.
  8462.  
  8463. Plusses, SE's and Classics are best used with sys 6, if at all possible
  8464. (again, sharing a printer might make it impossible). Faster, more memory
  8465. (max 4, you know). LC's only for the speed difference. At IIsi, it's
  8466. getting fast enough to consider upgrading to 7, but it does slow down...
  8467.  
  8468. About that printer problem... Anyone who knows a way to make a sys 6 Mac
  8469. work with the new printer drivers? Will 6.0.8 fix it? (Dumping in the
  8470. new drivers didn't.)
  8471.  
  8472. --
  8473. - -
  8474. Ingemar Ragnemalm, PhD
  8475. Image processing, Mac shareware games
  8476. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  8477.  
  8478. +++++++++++++++++++++++++++
  8479.  
  8480. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  8481. Date: Wed, 2 Mar 1994 19:41:30 GMT
  8482. Organization: (none)
  8483.  
  8484. L.H.Wood@lut.ac.uk writes:
  8485.  
  8486. >Aside: I've read that Apple are redoing the disk-cache
  8487. >code. Can we expect a disk cache whose size you don't set, that utilises free
  8488. >memory wherever it can, a la Windows NT, for System 7.5?
  8489.  
  8490. That could be nice, but even more important: will Apple get it act together
  8491. and fix the memory management overall? It seems like RamDoubler will fix
  8492. most of it for now, but fixes like that should go into the OS. Memory
  8493. protection would be nice too. (I suppose I won't get that from RamDoubler.)
  8494.  
  8495. --
  8496. - -
  8497. Ingemar Ragnemalm, PhD
  8498. Image processing, Mac shareware games
  8499. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  8500.  
  8501. +++++++++++++++++++++++++++
  8502.  
  8503. >From watkeyeh@dunx1.ocs.drexel.edu (Edwin H. Watkeys III)
  8504. Date: Thu, 3 Mar 1994 00:47:57 GMT
  8505. Organization: Drexel University
  8506.  
  8507. In article <CM1y4M.E9t@lysator.liu.se> ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  8508. >[A lot of stuff deleted]
  8509.  
  8510. There's no point in arguing -- the speed tradeoff is worth it to me. I'd
  8511. sooner use a typewriter than System 6.
  8512.  
  8513. >
  8514. >About that printer problem... Anyone who knows a way to make a sys 6 Mac
  8515. >work with the new printer drivers? Will 6.0.8 fix it? (Dumping in the
  8516. >new drivers didn't.)
  8517. >
  8518.  
  8519. I thought this was the reason 6.0.8 came out in the first place (to make
  8520. System 6 compatible with System 7.x printing drivers). Try it.
  8521.  
  8522. Ed
  8523. -- 
  8524. Ed Watkeys              watkeyeh@dunx1.ocs.drexel.edu  Drexel University
  8525. Philosopher-Programmer  EdWatkeys@distant.com           Distant Software
  8526.  
  8527. +++++++++++++++++++++++++++
  8528.  
  8529. >From Brad Koehn <koehn@macc.wisc.edu>
  8530. Date: 4 Mar 1994 01:17:08 GMT
  8531. Organization: University of Wisconsin
  8532.  
  8533. In article <CM1y4M.E9t@lysator.liu.se> Ingemar Ragnemalm,
  8534. ingemar@lysator.liu.se writes:
  8535. >I didn't say it won't work - it will, at least with 4 megs. I said that
  8536. >those Macs are so slow that they are *noticeably* more sluggish (at least
  8537. >in the Finder) when using System 7, and therefore many users won't
  8538. change.
  8539. >And as long as many users have a better life with the *old* system, it
  8540. >won't go away in a long time.
  8541. >
  8542. >I've tried Sys 7 on my SE. Never again. I use System 7 on my LC. I wish
  8543. >I didn't have to, but with sys 6 it can't print due to the sys 7-running
  8544. >IIfx that uses the same printer. When I switch the LC to sys 6 (I have
  8545. both
  8546. >on it, on separate disks) it feels like if I had plugged in an
  8547. accelerator
  8548. >board.
  8549. >
  8550. >Plusses, SE's and Classics are best used with sys 6, if at all possible
  8551. >(again, sharing a printer might make it impossible). Faster, more memory
  8552. >(max 4, you know). LC's only for the speed difference. At IIsi, it's
  8553. >getting fast enough to consider upgrading to 7, but it does slow down...
  8554. >
  8555. >About that printer problem... Anyone who knows a way to make a sys 6 Mac
  8556. >work with the new printer drivers? Will 6.0.8 fix it? (Dumping in the
  8557. >new drivers didn't.)
  8558.  
  8559. The printer problem is from using the System 7 LW Driver alongside the
  8560. System 6 LW Driver. Just put the Sys6 driver on the Sys7 machine and the
  8561. printer won't re-initialize every time you print from the other machine. 
  8562.  
  8563. Also, I agree that Sys7 is more sluggish than Sys6, but you have to take
  8564. into effect things like aliases (so you don't have to navigate to every
  8565. file) and AppleScript. System 7 lets the Finder do more, and if you take
  8566. advantage of the extra goodies, you can be more productive.
  8567.  
  8568. As someone (I believe it was Jon) pointed out, there are far more Sys7
  8569. Macs out there, and more and more software is Sys7 only. While there may
  8570. be some people out there that stick with Sys6, their number is getting
  8571. smaller every day. Also, Sys6 don't tend to buy lots of new software,
  8572. which is understandable, but doesn't help the "Sys7 required" trend.
  8573. _________________________________________________________________________
  8574. Brad Koehn          Data Transformations, Inc.        koehn@macc.wisc.edu
  8575.  
  8576. +++++++++++++++++++++++++++
  8577.  
  8578. >From worley@el.wpafb.af.mil (Rick Worley)
  8579. Date: Fri, 4 Mar 94 16:42:31 GMT
  8580. Organization: WL/ELM
  8581.  
  8582. >
  8583. >About that printer problem... Anyone who knows a way to make a sys 6 Mac
  8584. >work with the new printer drivers? Will 6.0.8 fix it? (Dumping in the
  8585. >new drivers didn't.)
  8586. >
  8587. 6.0.8 is available from ftp.apple.com//dts/sys.soft
  8588.  
  8589. 6.0.8 is compatible with System 7 laserwriter drivers
  8590.  
  8591. But you should install LaserWriter 8.1.1 on all your macs, it works with
  8592. both System 6 and 7.
  8593.  
  8594. Rick Worley                                                  Tel: (513) 255-7665
  8595. WL/ELM  BLDG 620                                             Fax: (513) 476-4807
  8596. 2241 AVIONICS CIRCLE SUITE 25                             worley@el.wpafb.af.mil
  8597. WRIGHT-PATTERSON AFB OH 45433-7327
  8598.  
  8599. +++++++++++++++++++++++++++
  8600.  
  8601. >From wbostow@hounix.org (Wayne Bostow)
  8602. Date: Sun, 06 Mar 1994 23:02:22 GMT
  8603. Organization: Houston UNIX Users Group (HOUNIX), Houston, TX
  8604.  
  8605.  
  8606. >But you should install LaserWriter 8.1.1 on all your macs, it works with
  8607. both System 6 and 7.
  8608.  
  8609.   Depends what you mean by "works".
  8610.  
  8611.   I heard this nonsense when sys 7 first came out and wasted a lot
  8612. of time with it before taking it off to use with my LaserWriterPlus.
  8613.  
  8614.   Thing is, with that printer, there is a max of about 128k free for
  8615. fonts using the sys 6 driver. Eat that away with the newer drivers
  8616. and you cannot print your existing documents.
  8617.  
  8618.   If you are working alone and are printing OK now, don't change.
  8619. -- 
  8620. __________________________________________________________
  8621.   Wayne Bostow "The HangulMan"
  8622.    10558 Alcott, Houston, TX 77043    ph. (713)468-6546
  8623.      wbostow@hounix.org
  8624.  
  8625. ---------------------------
  8626.  
  8627. >From pope@imv.aau.dk (Povl H. Pedersen)
  8628. Subject: Never beep when using GWorlds. System software bug!
  8629. Date: 6 Mar 1994 12:52:05 GMT
  8630. Organization: Information and Media Science, Aarhus University, DENMARK
  8631.  
  8632. I just had to help a guy who used my PICT file saving code.
  8633. He had some problems, and had inserted a SysBeep() in the bottleneck
  8634. procedure to write the bytes.
  8635.  
  8636. Now, the way my routine works is to create a new GWorld, SetGWorld,
  8637. OpenPicture, CopyBits, ClosePicture.
  8638.  
  8639. The problem is, that the machine he uses has the volume set to 0.
  8640. When my GWorld is set, and the SysBeep() tries to flash the menubar,
  8641. then the machine crashes each and every time! When I replaced the
  8642. the SetGWorld with a SetPort to the port of the FronWindow(), then I
  8643. got the flashing menu bar. Setting the sound volume > 0 gave me the
  8644. beeps instead.
  8645.  
  8646. So I would appreciate if some dude at Apple could look the code over,
  8647. and make sure that FlashMenuBar() is only called with a valid GWorld,
  8648. or sets/restores the window Gworld itself.
  8649.  
  8650. Now, this problem will probably get low priority, as it affects <10% of 
  8651. the Maacintosh users (those with sound level set to 0).
  8652.  
  8653. - -
  8654. Povl H. Pedersen  -  Macintosh Consultant and Programmer
  8655. System Administrator at the Aarhus Engineering School
  8656. pope@imv.aau.dk (preferred)  /  povlphp@uts.uni-c.dk
  8657.  
  8658. "Macintosh...for those who can see through Windows!"
  8659.  
  8660. +++++++++++++++++++++++++++
  8661.  
  8662. >From tgreen@ersys.edmonton.ab.ca (Terry Greeniaus)
  8663. Date: Thu, 10 Mar 94 15:46:30 MST
  8664. Organization: Edmonton Remote Systems #1
  8665.  
  8666. pope@imv.aau.dk (Povl H. Pedersen) writes:
  8667.  
  8668. > I just had to help a guy who used my PICT file saving code.
  8669. > He had some problems, and had inserted a SysBeep() in the bottleneck
  8670. > procedure to write the bytes.
  8671. > Now, the way my routine works is to create a new GWorld, SetGWorld,
  8672. > OpenPicture, CopyBits, ClosePicture.
  8673. > The problem is, that the machine he uses has the volume set to 0.
  8674. > When my GWorld is set, and the SysBeep() tries to flash the menubar,
  8675. > then the machine crashes each and every time! When I replaced the
  8676. > the SetGWorld with a SetPort to the port of the FronWindow(), then I
  8677. > got the flashing menu bar. Setting the sound volume > 0 gave me the
  8678. > beeps instead.
  8679. > So I would appreciate if some dude at Apple could look the code over,
  8680. > and make sure that FlashMenuBar() is only called with a valid GWorld,
  8681. > or sets/restores the window Gworld itself.
  8682. > Now, this problem will probably get low priority, as it affects <10% of 
  8683. > the Maacintosh users (those with sound level set to 0).
  8684. Well, I have also had problems with GWorlds, (offscreen ports, actually, 
  8685. but it's on a related topice.).  If you are set to a port somewhere 
  8686. offscreen, and call SetWTitle() it will try to draw the window into your 
  8687. port off screen, and make funny things appear.  (I'm not sure if the 
  8688. Inside Mac description says the set the port to the window who's title 
  8689. you're going to change, but that solved the problem.)
  8690.  
  8691.  
  8692. "Yes, I have tricks in my pocket, I have things up my sleeve.  But I am 
  8693. the opposite of a stage magician.  He gives you illusion that has the 
  8694. appearance of truth.  I give you truth in the pleasant disguise of 
  8695. illusion."
  8696.                                 --Tom Wingfield
  8697.                                 from "The Glass Menagerie" by T. Williams
  8698.  
  8699. +++++++++++++++++++++++++++
  8700.  
  8701. >From markhanrek@aol.com (MarkHanrek)
  8702. Date: 12 Mar 1994 04:37:00 -0500
  8703. Organization: America Online, Inc. (1-800-827-6364)
  8704.  
  8705. I could be wrong, but I believe your problems has to do with the graphic device
  8706. involved.
  8707.  
  8708. It is a common "programming error" to not restore the graphic device along with
  8709. the GWorld when working with GWorlds. This often happens when mixing the use of
  8710. GetPort/SetPort and GetGWorld/SetGWorld calls.
  8711.  
  8712. The guy who was having the problems using sysbeep was doing something
  8713. incorrect, and it doesn't seem it is the system's responsibility to protect
  8714. against a "programming error".
  8715.  
  8716. The call to SysBeep should have been bracketed with the appropriate
  8717. Get/SetGWorld calls to save and restore the port AND the graphic device.
  8718. Actually, the System crashed because the graphic device for the monitor the
  8719. menubar is on was not the currently active graphic device, I suspect.
  8720.  
  8721. If Apple fixed SysBeep to be self protecting, then a jillion other routines
  8722. would deserve upgrade. So you can see the problem.
  8723.  
  8724. It sounds like I am saying it is your friend's fault, :) but actually it is the
  8725. fault of less-than-adequate information management and accessibility here in
  8726. the future.  We developers have to know too much, and have yet to really use
  8727. our computers to help alleviate this burden in a coordinated way.
  8728.  
  8729. Hope this helps.
  8730.  
  8731. Mark Hanrek
  8732. The Information Workshop
  8733.  
  8734.  
  8735. +++++++++++++++++++++++++++
  8736.  
  8737. >From rmah@panix.com (Robert S. Mah)
  8738. Date: Sat, 12 Mar 1994 10:13:04 -0500
  8739. Organization: One Step Beyond
  8740.  
  8741. markhanrek@aol.com (MarkHanrek) wrote:
  8742.  
  8743. > [...]
  8744. > The call to SysBeep should have been bracketed with the appropriate
  8745. > Get/SetGWorld calls to save and restore the port AND the graphic device.
  8746. >[...]
  8747.  
  8748. I have to disagree.  If SysBeep() normally affected the screen then, yes,
  8749. it should be the application programmers responsibility to set/restore 
  8750. the GWorld, but the menu bar flashing behaviour is a special case inside
  8751. SysBeep() and not part of it's "standard" behaviour.  Thus, it is SysBeep
  8752. that should be setting/restoring the GWorld.
  8753.  
  8754. Of course, given the existance of this bug, the point is mute as the app
  8755. programmer _must_ set/restore the GWorld when calling SysBeep() in order
  8756. to have his stuff work.  C'est la vie.
  8757.  
  8758. Cheers,
  8759. Rob
  8760. ________________________________________________________________________
  8761.  Robert S. Mah              One Step Beyond              rmah@panix.com
  8762.  
  8763. +++++++++++++++++++++++++++
  8764.  
  8765. >From tgreen@ersys.edmonton.ab.ca (Terry Greeniaus)
  8766. Date: Sun, 13 Mar 94 15:42:40 MST
  8767. Organization: Edmonton Remote Systems #2
  8768.  
  8769. rmah@panix.com (Robert S. Mah) writes:
  8770.  
  8771. > markhanrek@aol.com (MarkHanrek) wrote:
  8772. > > [...]
  8773. > > The call to SysBeep should have been bracketed with the appropriate
  8774. > > Get/SetGWorld calls to save and restore the port AND the graphic device.
  8775. > >[...]
  8776. > I have to disagree.  If SysBeep() normally affected the screen then, yes,
  8777. > it should be the application programmers responsibility to set/restore 
  8778. > the GWorld, but the menu bar flashing behaviour is a special case inside
  8779. > SysBeep() and not part of it's "standard" behaviour.  Thus, it is SysBeep
  8780. > that should be setting/restoring the GWorld.
  8781. > Of course, given the existance of this bug, the point is mute as the app
  8782. > programmer _must_ set/restore the GWorld when calling SysBeep() in order
  8783. > to have his stuff work.  C'est la vie.
  8784. > Cheers,
  8785. > Rob
  8786.  
  8787. Well, if you're worried, at the start of your application, you could 
  8788. check the sound level and see if it was zero.  Then set a Boolean 
  8789. variable to true if it is non-zero or false if it is zero.  Then you 
  8790. could write some routine:
  8791. void MySysBeep()
  8792. {
  8793.    if (beepFlag)
  8794.       SysBeep(1);
  8795.    else
  8796.    {
  8797.       // Either save the current GWorld or not beep at all
  8798.       // SysBeep();
  8799.       // Reset the current GWorld
  8800.    }
  8801. }
  8802. and then replace all your calls to SysBeep(1) with MySysBeep(); .
  8803.  
  8804. There ya go! :-)
  8805.  
  8806. "Yes, I have tricks in my pocket, I have things up my sleeve.  But I am 
  8807. the opposite of a stage magician.  He gives you illusion that has the 
  8808. appearance of truth.  I give you truth in the pleasant disguise of 
  8809. illusion."
  8810.                                 --Tom Wingfield
  8811.                                 from "The Glass Menagerie" by T. Williams
  8812.  
  8813. +++++++++++++++++++++++++++
  8814.  
  8815. >From Ralph Martin <Ralph.Martin@cm.cf.ac.uk>
  8816. Date: Mon, 14 Mar 1994 16:22:13 +0000
  8817. Organization: University of Wales College of Cardiff
  8818.  
  8819. In article <T0D6ic3w165w@ersys.edmonton.ab.ca> Terry Greeniaus,
  8820. tgreen@ersys.edmonton.ab.ca writes:
  8821. >Well, if you're worried, at the start of your application, you could 
  8822. >check the sound level and see if it was zero.  Then set a Boolean 
  8823. >variable to true if it is non-zero or false if it is zero.  Then you 
  8824. >could write some routine:
  8825. >void MySysBeep()
  8826. >{
  8827. >   if (beepFlag)
  8828. >      SysBeep(1);
  8829. >   else
  8830. >   {
  8831. >      // Either save the current GWorld or not beep at all
  8832. >      // SysBeep();
  8833. >      // Reset the current GWorld
  8834. >   }
  8835. >}
  8836. >and then replace all your calls to SysBeep(1) with MySysBeep(); .
  8837.  
  8838. And then when the user changes the sound level AFTER your program has
  8839. started?
  8840.  
  8841. Kaboom...
  8842.  
  8843. +++++++++++++++++++++++++++
  8844.  
  8845. >From jwbaxter@olympus.net (John W. Baxter)
  8846. Date: Mon, 14 Mar 1994 09:06:57 -0800
  8847. Organization: Internet for the Olympic Peninsula
  8848.  
  8849. In article <T0D6ic3w165w@ersys.edmonton.ab.ca>, tgreen@ersys.edmonton.ab.ca
  8850. (Terry Greeniaus) wrote:
  8851.  
  8852. Discussion of the need to save/restore GWorlds before SysBeep () omitted
  8853.  
  8854. > Well, if you're worried, at the start of your application, you could 
  8855. > check the sound level and see if it was zero.  Then set a Boolean 
  8856. > variable to true if it is non-zero or false if it is zero.  Then you 
  8857. > could write some routine:  [omitted]
  8858.  
  8859. Not at the start of the application:  the user can change the sound level
  8860. any time your app calls WaitNextEvent ().  YOU wouldn't do that...but the
  8861. whole point of the exercise is to make your code work on other people's
  8862. machines.
  8863. -- 
  8864. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  8865.    jwbaxter@pt.olympus.net
  8866.  
  8867. +++++++++++++++++++++++++++
  8868.  
  8869. >From jim_reekes@quickmail.apple.com (Jim Reekes)
  8870. Date: Tue, 15 Mar 1994 06:29:45 GMT
  8871. Organization: Apple Computer, Inc.
  8872.  
  8873. In article <rmah-120394101304@rmah.dialup.access.net>, rmah@panix.com
  8874. (Robert S. Mah) wrote:
  8875. > markhanrek@aol.com (MarkHanrek) wrote:
  8876. > > [...]
  8877. > > The call to SysBeep should have been bracketed with the appropriate
  8878. > > Get/SetGWorld calls to save and restore the port AND the graphic device.
  8879. > >[...]
  8880. > I have to disagree.  If SysBeep() normally affected the screen then, yes,
  8881. > it should be the application programmers responsibility to set/restore 
  8882. > the GWorld, but the menu bar flashing behaviour is a special case inside
  8883. > SysBeep() and not part of it's "standard" behaviour.  Thus, it is SysBeep
  8884. > that should be setting/restoring the GWorld.
  8885. > Of course, given the existance of this bug, the point is mute as the app
  8886. > programmer _must_ set/restore the GWorld when calling SysBeep() in order
  8887. > to have his stuff work.  C'est la vie.
  8888.  
  8889. Well, I wrote SysBeep and I simply use the following code.
  8890.  
  8891.     FlashMenuBar(0);                                // just flash entire menu bar
  8892.     Delay(kMenuBarDelayTime, &finalTick);
  8893.     FlashMenuBar(0);
  8894.  
  8895. If anyone is NOT saving/restoring the GWorlds, it could be the Menu
  8896. Manager.
  8897.  
  8898. I missed the original message, but this is not a sound manager bug.
  8899.  
  8900. - ---------------------------------------------------------------------
  8901. Jim Reekes, Polterzeitgeist   |     Macintosh Toolbox Engineering
  8902.                               |          Sound Manager Expert
  8903. Apple Computer, Inc.          | "All opinions expressed are mine, and do
  8904. 20525 Mariani Ave. MS 302-3KS |   not necessarily represent those of my
  8905. Cupertino, CA 95014           |       employer, Apple Computer Inc."
  8906.  
  8907. +++++++++++++++++++++++++++
  8908.  
  8909. >From qsi@cnh.wlink.nl (Peter Kocourek)
  8910. Date: Tue, 15 Mar 1994 00:04:37 +0100
  8911. Organization: (none)
  8912.  
  8913. Terry Greeniaus wrote:
  8914.  
  8915.  TG> Well, if you're worried, at the start of your application, 
  8916.  TG> you could check the sound level and see if it was zero. Then 
  8917.  TG> set a Boolean variable to true if it is non-zero or false if 
  8918.  TG> it is zero. Then you could write some routine: 
  8919.  
  8920. No, you should check the sound level every time just before the SysBeep,
  8921. because users can and do change the sound level while your app is running.
  8922.  
  8923.  
  8924. YHS:QSI!
  8925.  
  8926.  
  8927. +++++++++++++++++++++++++++
  8928.  
  8929. >From KLUEV@jonathan.srcc.msu.su
  8930. Date: Wed, 16 Mar 1994 21:02:49 +0300
  8931. Organization: (none)
  8932.  
  8933. In article <763696813.AA01334@cnh.wlink.nl>
  8934. qsi@cnh.wlink.nl (Peter Kocourek) writes:
  8935. >Terry Greeniaus wrote:
  8936. >
  8937. > TG> Well, if you're worried, at the start of your application, 
  8938. > TG> you could check the sound level and see if it was zero. Then 
  8939. > TG> set a Boolean variable to true if it is non-zero or false if 
  8940. > TG> it is zero. Then you could write some routine: 
  8941. >
  8942. >No, you should check the sound level every time just before the SysBeep,
  8943. >because users can and do change the sound level while your app is running.
  8944.  
  8945. (SoundLevel <> 0) doesn't lead to (There will be sound, and not flash).
  8946.  
  8947. Michael Kluev.
  8948.  
  8949. ---------------------------
  8950.  
  8951. >From ViviStar@ACM.org (Jonathan Hess)
  8952. Subject: PPC & 68k UPP problems
  8953. Date: Tue, 1 Mar 1994 00:56:35 GMT
  8954. Organization: ViviStar Consulting
  8955.  
  8956. I've reviewed "Making the Leap to PowerPC" article in develop 16 but
  8957. find its description of Universal ProcPtrs lacking.  Particularly in
  8958. relation to coding source that is compatible with both 68k and PowerPC
  8959. systems.
  8960.  
  8961. Using the code snippets from that article would lead one to believe
  8962. that a global declaration of:
  8963.  
  8964.     RoutineDescriptor gVActionProcRD = BUILD_ROUTINE_DESCRIPTOR(
  8965.         uppControlActionProcInfo, VActionProc);
  8966.  
  8967. with code such as:
  8968.  
  8969.     TrackControl(ctlHit, mouseLoc, (ControlActionUPP) &gVActionProcRD);
  8970.  
  8971. would work under both PowerPC and 68k systems.  While this might work
  8972. with PowerPC systems it clearly will not work with 68k systems --
  8973. VActionProc should be passed in the TrackControl call but taking the
  8974. address of gVActionProcRD can not possibly return that appropriate
  8975. address.
  8976.  
  8977. Anyone have some sample code you could link me or that I could ftp from
  8978. somewhere?
  8979.  
  8980. Thanks,
  8981. Jonathan Hess
  8982. ViviStar Consulting
  8983.  
  8984. +++++++++++++++++++++++++++
  8985.  
  8986. >From zstern@adobe.com (Zalman Stern)
  8987. Date: Tue, 1 Mar 1994 12:25:29 GMT
  8988. Organization: Adobe Systems Incorporated
  8989.  
  8990. Jonathan Hess writes
  8991. > I've reviewed "Making the Leap to PowerPC" article in develop 16 but
  8992. > find its description of Universal ProcPtrs lacking.  Particularly in
  8993. > relation to coding source that is compatible with both 68k and PowerPC
  8994. > systems.
  8995. > Using the code snippets from that article would lead one to believe
  8996. > that a global declaration of:
  8997. >     RoutineDescriptor gVActionProcRD = BUILD_ROUTINE_DESCRIPTOR(
  8998. >         uppControlActionProcInfo, VActionProc);
  8999. > with code such as:
  9000. >     TrackControl(ctlHit, mouseLoc, (ControlActionUPP) &gVActionProcRD);
  9001. > would work under both PowerPC and 68k systems.  While this might work
  9002. > with PowerPC systems it clearly will not work with 68k systems --
  9003. > VActionProc should be passed in the TrackControl call but taking the
  9004. > address of gVActionProcRD can not possibly return that appropriate
  9005. > address.
  9006. > Anyone have some sample code you could link me or that I could ftp from
  9007. > somewhere?
  9008.  
  9009. I'd do something like this. In a header file have the following:
  9010.  
  9011.     #if NEEDROUTINEDESCRIPTORS
  9012.     #define MakeStaticRoutineDesc(name, procinfo) \
  9013.         RoutineDescriptor name##RDS = \
  9014.             BUILD_ROUTINE_DESCRIPTOR(procinfo, name);
  9015.     #else
  9016.     #define MakeStaticRoutineDesc(name, procinfo)
  9017.     #endif
  9018.  
  9019.     #if NEEDROUTINEDESCRIPTORS
  9020.     #define ExternRoutineDescriptor(name) \
  9021.         extern RoutineDescriptor name##RDS;
  9022.     #else
  9023.     #define ExternRoutineDesc(name)
  9024.     #ednif
  9025.  
  9026.     #if NEEDROUTINEDESCRIPTORS
  9027.     #define ConditionalRD(name) (&name##RDS)
  9028.     #else
  9029.     #define ConditionalRD(name) (&name)
  9030.     #endif
  9031.  
  9032. To use this write code like so:
  9033.  
  9034.     pascal void VActionProc(ControlHandle theControl, short partCode)
  9035.     {
  9036.     /* ... */
  9037.     }
  9038.  
  9039.     MakeStaticRoutineDesc(VActionProc, uppControlActionProcInfo)
  9040.  
  9041.     {
  9042.         TrackControl(ctlHit, mouseLoc, (ControlActionUPP)  
  9043. ConditionalRD(VActionProc));
  9044.     }
  9045.  
  9046. The ExternRoutineDesc macro is used in addition to existing extern  
  9047. prototypes in header files. (Ideally, the Apple header files would declare a  
  9048. direct function type for each callback in addition to the function pointer  
  9049. type, but they don't. If they did, ExternRoutineDesc could declare either a  
  9050. function or a RoutineDescriptor structure.)
  9051. --
  9052. Zalman Stern           zalman@adobe.com            (415) 962 3824
  9053. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  9054. "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)
  9055.  
  9056. +++++++++++++++++++++++++++
  9057.  
  9058. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  9059. Date: 1 Mar 1994 19:50:23 GMT
  9060. Organization: Royal Institute of Technology, Stockholm, Sweden
  9061.  
  9062. In <CLynyC.G8v@news.direct.net> ViviStar@ACM.org (Jonathan Hess) writes:
  9063.  
  9064. >Using the code snippets from that article would lead one to believe
  9065. >that a global declaration of:
  9066.  
  9067. >    RoutineDescriptor gVActionProcRD = BUILD_ROUTINE_DESCRIPTOR(
  9068. >        uppControlActionProcInfo, VActionProc);
  9069.  
  9070. >would work under both PowerPC and 68k systems.  While this might work
  9071. >with PowerPC systems it clearly will not work with 68k systems --
  9072. >VActionProc should be passed in the TrackControl call but taking the
  9073. >address of gVActionProcRD can not possibly return that appropriate
  9074. >address.
  9075.  
  9076. No, but it might be that under the 68k environment, the routine
  9077. descriptor includes a JMP instruction and the address...
  9078.  
  9079. However, that doesn't appear to be the case; instead, you're
  9080. supposed to call NewControlActionProc which WILL work on both
  9081. kinds of systems.
  9082.  
  9083. Cheers,
  9084.  
  9085.                         / h+
  9086. -- 
  9087.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  9088.  "Don't use the Layer Manager"
  9089.  
  9090. +++++++++++++++++++++++++++
  9091.  
  9092. >From t-gaul@i-link.com (Troy Gaul)
  9093. Date: Wed, 02 Mar 1994 15:29:32 -0600
  9094. Organization: I-Link, Ltd.
  9095.  
  9096. In article <2l069v$mt4@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte)
  9097. wrote:
  9098.  
  9099. > In <CLynyC.G8v@news.direct.net> ViviStar@ACM.org (Jonathan Hess) writes:
  9100. > >Using the code snippets from that article would lead one to believe
  9101. > >that a global declaration of:
  9102. > >    RoutineDescriptor gVActionProcRD = BUILD_ROUTINE_DESCRIPTOR(
  9103. > >        uppControlActionProcInfo, VActionProc);
  9104. > >would work under both PowerPC and 68k systems.  While this might work
  9105. > >with PowerPC systems it clearly will not work with 68k systems --
  9106. > >VActionProc should be passed in the TrackControl call but taking the
  9107. > >address of gVActionProcRD can not possibly return that appropriate
  9108. > >address.
  9109. > No, but it might be that under the 68k environment, the routine
  9110. > descriptor includes a JMP instruction and the address...
  9111. > However, that doesn't appear to be the case; instead, you're
  9112. > supposed to call NewControlActionProc which WILL work on both
  9113. > kinds of systems.
  9114.  
  9115. Yeah, but that creates it in the heap (on PowerPC), not on the stack, which
  9116. can be advantageous at times. Zalman Stern recently posted a technique in
  9117. this thread that allows you to create a static routine descriptor, which it
  9118. looked like, would also work for stack-based RDs. 
  9119.  
  9120. This can be useful for things like DeviceLoop drawing procs that don't have
  9121. to stay around for long to avoid creating and disposing in the heap all of
  9122. the time (in code like a WDEF that, on the 68K, can't have global data -- I
  9123. know that it can on the PowerPC, but I wanted to do it in a portable way
  9124. for if/when RDs are supported on 68K).
  9125.  
  9126. _troy
  9127. //////// //////___Troy Gaul_________________________t-gaul@i-link.com__ //
  9128.   //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
  9129.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
  9130. //    //////________________________________________________________ //
  9131.  
  9132. ---------------------------
  9133.  
  9134. >From arose@ATHENA.MIT.EDU (Alex Rosen)
  9135. Subject: PPC binaries
  9136. Date: 7 Mar 1994 17:05:23 GMT
  9137. Organization: Massachusetts Institute of Technology
  9138.  
  9139. (1) Since PPC code is in the data fork and 68k code is in the resource
  9140. fork:  Would it be possible to embed a tiny 68k app in my PPC app,
  9141. which just pops up a dialog saying "This program is for PPC computers,
  9142. please install the 68k version" or something like that?
  9143.  
  9144. (2) I assume that CodeWarrior and the Apple SDK don't use any of the
  9145. instructions on the 601 that aren't part of the PPC spec, and that may
  9146. not be around on future chips.  Is this so?  Might these instructions be
  9147. emulated via traps on future chips?
  9148.  
  9149. (3) Has Apple said anything about low memory globals on PPC?  If Apple
  9150. were to release a system with memory protection, it would seem that all
  9151. apps which access LMGs directly would break, and there are plenty of
  9152. these apps around.  But it seems that recompiling for PPC is the perfect
  9153. time for developers to replace this code with system software calls
  9154. (e.g.  GetMBarHeight(), SetMBarHeight() ).  Any word from Apple on this?
  9155.  
  9156. --Alex
  9157.  
  9158.  
  9159. +++++++++++++++++++++++++++
  9160.  
  9161. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  9162. Date: 7 Mar 1994 19:13:25 GMT
  9163. Organization: Royal Institute of Technology, Stockholm, Sweden
  9164.  
  9165. In <2lfmsj$otv@senator-bedfellow.MIT.EDU> arose@ATHENA.MIT.EDU (Alex Rosen) writes:
  9166.  
  9167. >(1) Since PPC code is in the data fork and 68k code is in the resource
  9168. >fork:  Would it be possible to embed a tiny 68k app in my PPC app,
  9169. >which just pops up a dialog saying "This program is for PPC computers,
  9170. >please install the 68k version" or something like that?
  9171.  
  9172. It's not only possible, it's THE LAW, unless you shiip a fat
  9173. binary.
  9174.  
  9175. Now, should you embed a tiny PEF that says "this application is only
  9176. for 68k Macs" ? :-)
  9177.  
  9178. There is sample code on the SDK to show this, though it's really
  9179. as trivial as building:
  9180.  
  9181. void
  9182. main ( void ) {
  9183.     InitGraf ( & qd . thePort ) ;
  9184.     InitFonts ( ) ;
  9185.     InitWindows ( ) ;
  9186.     InitMenus ( ) ;
  9187.     TEInit ( ) ;
  9188.     InitDialogs ( ) ;
  9189.     Alert ( 666 , NULL ) ;
  9190. }
  9191.  
  9192. and pasting your app resources into the native (nee, "optimized")
  9193. app.
  9194.  
  9195. >(2) I assume that CodeWarrior and the Apple SDK don't use any of the
  9196. >instructions on the 601 that aren't part of the PPC spec, and that may
  9197. >not be around on future chips.  Is this so?  Might these instructions be
  9198. >emulated via traps on future chips?
  9199.  
  9200. They're all clean.
  9201.  
  9202. >(3) Has Apple said anything about low memory globals on PPC?  If Apple
  9203.  
  9204. Yeah, they're still there (if you call LMGetCurDeactive() or LMSetXXX)
  9205. However, in the future, the programming model might rid itself of
  9206. lo-mem globals.
  9207.  
  9208. -- 
  9209.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  9210.  
  9211.    There's no problem that can't be solved using brute-force algorithms
  9212.    and a sufficiently fast computer. Ergo, buy more hardware.    (NOT!)
  9213.  
  9214. +++++++++++++++++++++++++++
  9215.  
  9216. >From gdl@stlawrence.maths (Mr_G._Landweber_student_tel_2-73550)
  9217. Date: 07 Mar 1994 23:38:36 GMT
  9218. Organization: (none)
  9219.  
  9220. In article <2lfmsj$otv@senator-bedfellow.MIT.EDU> arose@ATHENA.MIT.EDU (Alex Rosen) writes:
  9221.    (3) Has Apple said anything about low memory globals on PPC?  If Apple
  9222.    were to release a system with memory protection, it would seem that all
  9223.    apps which access LMGs directly would break, and there are plenty of
  9224.    these apps around.  But it seems that recompiling for PPC is the perfect
  9225.    time for developers to replace this code with system software calls
  9226.    (e.g.  GetMBarHeight(), SetMBarHeight() ).  Any word from Apple on this?
  9227.  
  9228. As of the first PowerMacs, all the low memory globals--both documented
  9229. and not--are still there.  However, the universal header files for
  9230. compling PowerPC native (and 680x0) apps no longer define these
  9231. globals.  They use "Get..." and "Set..." macros instead.
  9232.  
  9233. -- Greg "Buttons" Landweber
  9234.    gdl@maths.ox.ac.uk
  9235.  
  9236. +++++++++++++++++++++++++++
  9237.  
  9238. >From DACRXL01.OURX124@tcp30.dx.deere.com (Juan Ingles)
  9239. Date: Tue, 8 Mar 1994 18:16:12 GMT
  9240. Organization: Proteus Ventures, Inc.
  9241.  
  9242. In article <2lfucm$21c@news.kth.se>
  9243. d88-jwa@mumrik.nada.kth.se (Jon W‰tte) writes:
  9244.  
  9245. > void
  9246. > main ( void ) {
  9247. >         InitGraf ( & qd . thePort ) ;
  9248. >         InitFonts ( ) ;
  9249. >         InitWindows ( ) ;
  9250. >         InitMenus ( ) ;
  9251. >         TEInit ( ) ;
  9252. >         InitDialogs ( ) ;
  9253. >         Alert ( 666 , NULL ) ;
  9254. > }
  9255.  
  9256. InitDialogs ( )  should be: InitDialogs ( NULL )
  9257.  
  9258. Tsk... Tsk... Jon, you forgot your resumeProc Ptr.  :)
  9259.  
  9260. >-- 
  9261. > -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  9262. >There's no problem that can't be solved using brute-force algorithms
  9263. >and a sufficiently fast computer. Ergo, buy more hardware.    (NOT!)
  9264.  
  9265. There's no code that can't be optimized. Ergo, spend the rest of your
  9266. life optimizing code, and in the end the code won't take any time to
  9267. run at all. ;)
  9268.  
  9269. Juan Ingles
  9270. <DACRXL01.OURX124@tcp30.dx.deere.com>
  9271. --
  9272. Proteus Ventures, Inc. - Computer Software Consulting and Development
  9273.     1514 Oriole Ave * Waterloo, IA 50701 * (319) 232-0985
  9274.  
  9275. +++++++++++++++++++++++++++
  9276.  
  9277. >From ejf0@ns1.cc.lehigh.edu (EUGENE JOSEPH FOSS)
  9278. Date: Thu, 10 Mar 1994 03:34:55 GMT
  9279. Organization: Lehigh University
  9280.  
  9281. Jon W‰tte (d88-jwa@mumrik.nada.kth.se) wrote:
  9282.  
  9283. : Now, should you embed a tiny PEF that says "this application is only
  9284. : for 68k Macs" ? :-)
  9285.  
  9286. Well, you could if you wanted too, but wouldn't it be a little silly?  I mean,
  9287. since all the PPC Macs include 68k emulation...
  9288.  
  9289.  
  9290. -- 
  9291.      Eugene Foss                                         CS/Math/Cog. Sci.
  9292.      ---------------------------------------------------------------------
  9293.        "Eating meat on Fridays may not be a mortal sin anymore, but I
  9294.         bet there are still some guys in hell doing time on a meat rap."
  9295.  
  9296. +++++++++++++++++++++++++++
  9297.  
  9298. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  9299. Date: 10 Mar 1994 10:30:50 GMT
  9300. Organization: Royal Institute of Technology, Stockholm, Sweden
  9301.  
  9302.  
  9303. >: Now, should you embed a tiny PEF that says "this application is only
  9304. >: for 68k Macs" ? :-)
  9305.  
  9306. >Well, you could if you wanted too, but wouldn't it be a little silly?  I mean,
  9307. >since all the PPC Macs include 68k emulation...
  9308.  
  9309. There WAS a smiley there after all.
  9310.  
  9311. The more relevant reason being there may be a PPC version, and
  9312. users should know they're losing out on performance.
  9313.  
  9314. So, your installer could choose between installing
  9315. 1) Full fat binary
  9316. 2) PPC code with tiny 68k alert
  9317. 3) 68k code with tiny PEF alert
  9318.  
  9319. Cheers,
  9320.  
  9321.                     / h+
  9322. -- 
  9323.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  9324.    The word "politics" is derived from the word "poly", meaning
  9325.    "many", and the word "ticks", meaning "blood sucking parasites".
  9326.                      -- Larry Hardiman
  9327.  
  9328. +++++++++++++++++++++++++++
  9329.  
  9330. >From zstern@adobe.com (Zalman Stern)
  9331. Date: Thu, 10 Mar 1994 18:59:10 GMT
  9332. Organization: Adobe Systems Incorporated
  9333.  
  9334. Jon W tte writes
  9335. > >: Now, should you embed a tiny PEF that says "this application is only
  9336. > >: for 68k Macs" ? :-)
  9337. > >Well, you could if you wanted too, but wouldn't it be a little silly?  I  
  9338. mean,
  9339. > >since all the PPC Macs include 68k emulation...
  9340. > There WAS a smiley there after all.
  9341. > The more relevant reason being there may be a PPC version, and
  9342. > users should know they're losing out on performance.
  9343. > So, your installer could choose between installing
  9344. > 1) Full fat binary
  9345. > 2) PPC code with tiny 68k alert
  9346. > 3) 68k code with tiny PEF alert
  9347.  
  9348. Its just as easy to gestalt for the PowerPC in your 68k code. However, there  
  9349. is an interesting question there about how one should differentiate between  
  9350. running PowerPC and 68K code. A good solution is to put something in the  
  9351. splash screen. (At least for apps with heavy weight splash screens.)  
  9352. Likewise, this would appear in the about box. The question is what should be  
  9353. there?
  9354. --
  9355. Zalman Stern           zalman@adobe.com            (415) 962 3824
  9356. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  9357. "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)
  9358.  
  9359. ---------------------------
  9360.  
  9361. >From gewekean@studentg.msu.edu (Andrew Geweke)
  9362. Subject: Passing data through to completion procs?
  9363. Date: Wed, 16 Mar 1994 22:06:40 -0500
  9364. Organization: Michigan State University
  9365.  
  9366. What I'm doing is writing an interface library to MacTCP; I want it to be 
  9367. simple. All routines are async, so I just want to have the caller pass in a 
  9368. simple structure pointer; a field in the struct gets changed when the call 
  9369. completes. I want to do this rather than having the user ravage through large 
  9370. ParamBlocks and so forth for simplicity and so on.
  9371.  
  9372. My question is this: How can I get the Device Manager to pass four bytes to a 
  9373. completion routine that I pass in when I make the call?
  9374.  
  9375. Basically, I'm having trouble getting a pointer to the structure through to 
  9376. the completion routine. Is there any place I can stash this? I'm looking 
  9377. through the ParamBlock structure right now, and everything's used or "not 
  9378. used" (which, as we all know, means reserved -- I don't want to break rules 
  9379. here).
  9380.  
  9381. Here are my ideas so far:
  9382.  
  9383. (1) Set the user up with a pointer to the ioResult field. Disadvantage: I 
  9384. want to deallocate the parameter-block's memory as soon as the call 
  9385. completes. This would require the user to do this.
  9386.  
  9387. (2) Create a linked list of all outstanding calls with pointers to their 
  9388. parameter blocks. This is a roundabout method, though it should work; 
  9389. however, I'd rather not.
  9390.  
  9391. Basically, I'm converting async calls from the beasts that they are into 
  9392. simple ones; you pass in a struct with only the specific information that 
  9393. gets a flag set when it's done. Any ideas?
  9394.  
  9395.  
  9396.  
  9397.  
  9398.  
  9399. +++++++++++++++++++++++++++
  9400.  
  9401. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  9402. Date: Thu, 17 Mar 1994 01:37:49 -0600
  9403. Organization: University of Illinois at Urbana-Champaign
  9404.  
  9405. In article <9403162206.AA40375@geweke.ppp.msu.edu>,
  9406. gewekean@studentg.msu.edu (Andrew Geweke) wrote:
  9407.  
  9408. >What I'm doing is writing an interface library to MacTCP;
  9409. >
  9410. >My question is this: How can I get the Device Manager to pass four bytes to a 
  9411. >completion routine that I pass in when I make the call?
  9412. >
  9413. >Basically, I'm having trouble getting a pointer to the structure through to 
  9414. >the completion routine. Is there any place I can stash this?
  9415.  
  9416. Since you're using MacTCP, you're in luck. Every MacTCP param block has a
  9417. userDataPtr field, which is exactly where you can store any pointer you
  9418. like.
  9419.  
  9420. Even if this field weren't there, you can do the same thing. Just make
  9421. your own personal parameter block which contains everything the real
  9422. parameter block does, plus one pointer field tacked onto the end. The
  9423. Device Manager and driver are only going to use the fields they specify,
  9424. so this is perfectly safe. (How could it not be? It would be quite ugly if
  9425. a device driver decided to use some memory past the end of its parameter
  9426. block!)
  9427.  
  9428. pr
  9429. -- 
  9430. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  9431. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  9432. System manager - Cognitive Science Group, Beckman Institute, UIUC
  9433. Internet: resnick@cogsci.uiuc.edu
  9434.  
  9435. +++++++++++++++++++++++++++
  9436.  
  9437. >From zben@ni.umd.edu (Charles B. Cranston)
  9438. Date: 18 Mar 1994 00:50:47 GMT
  9439. Organization: UMCP Network Infrastructures
  9440.  
  9441. In article <9403162206.AA40375@geweke.ppp.msu.edu>,
  9442. gewekean@studentg.msu.edu (Andrew Geweke) wrote:
  9443.  
  9444. > What I'm doing is writing an interface library to MacTCP; I want it to be 
  9445. > simple. All routines are async, so I just want to have the caller pass in a 
  9446. > simple structure pointer; a field in the struct gets changed when the call 
  9447. > completes. I want to do this rather than having the user ravage through large 
  9448. > ParamBlocks and so forth for simplicity and so on.
  9449.  
  9450. > My question is this: How can I get the Device Manager to pass four bytes to a 
  9451. > completion routine that I pass in when I make the call?
  9452.  
  9453. Another approach would be to erect a "trampoline" somewhere.  This would
  9454. be 8 bytes consisting of a JSr to the real handler followed by the four
  9455. data bytes.  The real handler immediately does a Move.L (A7)+,A0 and then
  9456. A0 points to the four data bytes, and the stacktop is now the real final
  9457. return address.
  9458.  
  9459. For MacTCP the UserData approach or the embed-IOPB-in-larger-known-block
  9460. approaches would both work.  I am thinking about using this trampoline
  9461. technique for EtherNet "Protocol Handlers" where the IOPB is not passed
  9462. to the callback routine.
  9463.  
  9464. The cost, of course, is allocating and freeing the memory space for
  9465. the trampoline, especially in the asynchronous environment you are
  9466. talking about.
  9467.  
  9468. ---------------------------
  9469.  
  9470. >From Dmitry Boldyrev <dmitry@atlas.chem.utah.edu>
  9471. Subject: Password editing item.. Tricky?
  9472. Date: 23 Feb 1994 02:22:25 GMT
  9473. Organization: University of Utah
  9474.  
  9475. Hi All.
  9476. I am wounding if anyone has implemented so called scrambled editing item
  9477. I looked at the ftp.apple.com and found a couple of codes which would do
  9478. it
  9479. but, I don't think it is the best way to do.. 
  9480. I am gonna use it for my FTP client. so, when I type my password "hello"
  9481. it should actually print on the display "!!!!!". and the buffer should
  9482. have "hello" so that I can then use it.
  9483. I am thinking that there should be a way of writing a small routine and
  9484. hook the interruption and everything what supposed to be displayed will
  9485. be taken care by that routine.. 
  9486. Any ideas how it can be implemented? (Pascal, C iz ok)
  9487. Thank you very much!
  9488.  
  9489. ......................................................................
  9490. . Dmitry Boldyrev                     . (_) (_)                      .
  9491. . University of Utah, Salt Lake City  .  |---| urricane, inc         .
  9492. . Utah, USA                           . (_) (_)                      .
  9493. . Home Tel: (801) 581-1298, Office Tel: (801) 581-5465               . 
  9494. ......................................................................
  9495.  
  9496. +++++++++++++++++++++++++++
  9497.  
  9498. >From infosafe@panix.com (Tom Lipscomb)
  9499. Date: 22 Feb 1994 23:57:18 -0500
  9500. Organization: PANIX Public Access Internet and Unix, NYC
  9501.  
  9502. The easiest solution I came up with was to make my own font, which had
  9503. one character (a diamond) for all of the letters.  Use this font for
  9504. the edit text that they are typing the password in.
  9505.  
  9506. Cheers,
  9507. Bradford Smith
  9508.  
  9509.  
  9510.  
  9511. +++++++++++++++++++++++++++
  9512.  
  9513. >From Jonathan D Baumgartner <Jonathan.D.Baumgartner@unh.edu>
  9514. Date: 23 Feb 1994 15:11:37 GMT
  9515. Organization: Computing & Information Services, University of New Hampshire
  9516.  
  9517. In article <2kenne$rku@panix2.panix.com> Tom Lipscomb, infosafe@panix.com
  9518. writes:
  9519. >The easiest solution I came up with was to make my own font, which had
  9520. >one character (a diamond) for all of the letters.  Use this font for
  9521. >the edit text that they are typing the password in.
  9522.  
  9523. That's an interesting solution; wish I'd thought of that earlier :-)
  9524.  
  9525. I did this by creating a dialog filter which I pass to ModalDialog.  When
  9526. a keyDown or autoKey event occurs, it takes the character, appends it to
  9527. a dummy string, and then changes the EventRecord's message to a bullet. 
  9528. This way you end up with a string that holds the password, but the user
  9529. only sees bullets on-screen.
  9530.  
  9531. I found a really excellent example (but HUGE, and it does a lot of other
  9532. stuff besides) in the source for John Norstad's NewsWatcher.
  9533.  
  9534. jon
  9535. --
  9536. Jonathan D. Baumgartner        Jonathan.D.Baumgartner@unh.edu 
  9537. Computing & Information Services, University of New Hampshire            
  9538.  
  9539.            "It's just a matter of opinion." -- Primus
  9540.  
  9541. +++++++++++++++++++++++++++
  9542.  
  9543. >From Scott_Gruby@hmc.edu (Scott Gruby)
  9544. Date: Wed, 23 Feb 1994 07:34:32 -0800
  9545. Organization: Harvey Mudd College, Claremont CA
  9546.  
  9547. In article <2kfrn9$d4v@mozz.unh.edu>, Jonathan D Baumgartner
  9548. <Jonathan.D.Baumgartner@unh.edu> wrote:
  9549.  
  9550. > I did this by creating a dialog filter which I pass to ModalDialog.  When
  9551. > a keyDown or autoKey event occurs, it takes the character, appends it to
  9552. > a dummy string, and then changes the EventRecord's message to a bullet. 
  9553. > This way you end up with a string that holds the password, but the user
  9554. > only sees bullets on-screen.
  9555. > I found a really excellent example (but HUGE, and it does a lot of other
  9556. > stuff besides) in the source for John Norstad's NewsWatcher.
  9557.  
  9558. There's a snippet on ftp.apple.com that shows 3 ways of doing this; 1 is
  9559. with a different font, 1 is as you described and I forgot what the 3rd one
  9560. was. Anyway there is an example that is really SMALL and very easy to
  9561. understand.
  9562. -- 
  9563. Scott Allen Gruby                         (Scott_Gruby@hmc.edu)
  9564. Macintosh Student System Manager
  9565. Academic Computing, Harvey Mudd College
  9566. Claremont, CA 91711
  9567.  
  9568. +++++++++++++++++++++++++++
  9569.  
  9570. >From mwalker@netcom.com (Mel Walker)
  9571. Date: Wed, 23 Feb 1994 17:01:30 GMT
  9572. Organization: Committee to Elect Dan Quayle Lord of the Cosmos
  9573.  
  9574. Dmitry Boldyrev (dmitry@atlas.chem.utah.edu) wrote:
  9575. : Hi All.
  9576. : I am wounding if anyone has implemented so called scrambled editing item
  9577. : I looked at the ftp.apple.com and found a couple of codes which would do
  9578. : it
  9579. : but, I don't think it is the best way to do.. 
  9580. : I am gonna use it for my FTP client. so, when I type my password "hello"
  9581. : it should actually print on the display "!!!!!". and the buffer should
  9582. : have "hello" so that I can then use it.
  9583. : I am thinking that there should be a way of writing a small routine and
  9584. : hook the interruption and everything what supposed to be displayed will
  9585. : be taken care by that routine.. 
  9586. : Any ideas how it can be implemented? (Pascal, C iz ok)
  9587. : Thank you very much!
  9588.  
  9589. My prefered way is to have two text boxes for the password, one of which 
  9590. is outside of the dialog (i.e., it's invisible). Use a filter routine in 
  9591. your modal dialog that puts keystrokes into the invisible field, and puts 
  9592. a ! into the visible field. Backspaces, selections, and the like affect 
  9593. both fields.
  9594. I may be explaining this badly. Send me email if you want more help.
  9595. -- 
  9596. Mel Walker                                   mwalker@netcom.com
  9597. "Natural exuberance is one of those qualities that makes us tigers so 
  9598. darn endearing!" -- Hobbes
  9599.  
  9600. +++++++++++++++++++++++++++
  9601.  
  9602. >From Dmitry Boldyrev <dmitry@atlas.chem.utah.edu>
  9603. Date: 23 Feb 1994 18:27:43 GMT
  9604. Organization: University of Utah
  9605.  
  9606. In article <2kfrn9$d4v@mozz.unh.edu> Jonathan D Baumgartner,
  9607. Jonathan.D.Baumgartner@unh.edu writes:
  9608. >That's an interesting solution; wish I'd thought of that earlier :-)
  9609. >
  9610. >I did this by creating a dialog filter which I pass to ModalDialog.  When
  9611. >a keyDown or autoKey event occurs, it takes the character, appends it to
  9612. >a dummy string, and then changes the EventRecord's message to a bullet. 
  9613. >This way you end up with a string that holds the password, but the user
  9614. >only sees bullets on-screen.
  9615. >
  9616. >I found a really excellent example (but HUGE, and it does a lot of other
  9617. >stuff besides) in the source for John Norstad's NewsWatcher.
  9618.  
  9619. Yeah, I know about the way of making such a font.. looks like it is the
  9620. only
  9621. solution I can think of. I've done the same way as Johnatan described, but
  9622. there iz a little problem. Suppose you want to show a password when you
  9623. create
  9624. a window.. How would you do it?
  9625. like I want !!!!!! to be shown when the dialog appears.. they way you
  9626. suggest
  9627. it it won't work.
  9628. Thanks for the replies, guys!
  9629.  
  9630. +++++++++++++++++++++++++++
  9631.  
  9632. >From Dmitry Boldyrev <dmitry@atlas.chem.utah.edu>
  9633. Date: 23 Feb 1994 18:28:57 GMT
  9634. Organization: University of Utah
  9635.  
  9636. In article <2kenne$rku@panix2.panix.com> Tom Lipscomb, infosafe@panix.com
  9637. writes:
  9638. >The easiest solution I came up with was to make my own font, which had
  9639. >one character (a diamond) for all of the letters.  Use this font for
  9640. >the edit text that they are typing the password in.
  9641. >
  9642. >Cheers,
  9643. >Bradford Smith
  9644.  
  9645. A little problem too.
  9646. How would you do it if you have two editing items?
  9647. When you change the font, it will make all TE items the same font.. ?
  9648. Thanks
  9649.  
  9650. Dmitry.
  9651.  
  9652. +++++++++++++++++++++++++++
  9653.  
  9654. >From hrafal@copernicus.bbn.com (Howie Rafal)
  9655. Date: 23 Feb 1994 19:24:30 GMT
  9656. Organization: BBN, Inc
  9657.  
  9658. In article <2kenne$rku@panix2.panix.com>, infosafe@panix.com (Tom Lipscomb)
  9659. wrote:
  9660. > The easiest solution I came up with was to make my own font, which had
  9661. > one character (a diamond) for all of the letters.  Use this font for
  9662. > the edit text that they are typing the password in.
  9663. > Cheers,
  9664. > Bradford Smith
  9665.  
  9666. Be careful to not allow copy in the item, because it could be pasted
  9667. somewhere else and the font changed.
  9668.  
  9669. I use a TCL class called CPasswordText that I could forward to you if you
  9670. want.  It actually uses a bullet character and maintains a text item
  9671. offscreen.  I also have classes for password dialogs which handle turning
  9672. on and off the OK button based on the login fields having values entered.
  9673.  
  9674.  
  9675. HOWIE.
  9676.  
  9677. +++++++++++++++++++++++++++
  9678.  
  9679. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  9680. Date: 24 Feb 1994 10:39:33 +0800
  9681. Organization: NCRPDA, Curtin University
  9682.  
  9683. infosafe@panix.com (Tom Lipscomb) writes:
  9684.  
  9685. >The easiest solution I came up with was to make my own font, which had
  9686. >one character (a diamond) for all of the letters.  Use this font for
  9687. >the edit text that they are typing the password in.
  9688.  
  9689. Don't spaces show up though?  Last time I tried this, the spaces showed up
  9690. even if your font didn't define the space character or even if you did,
  9691. it would show up as a space.  This was a long time back, maybe its changed?
  9692.    Peter.
  9693. -- 
  9694. _______________________________________________________________________
  9695. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  9696.  
  9697. +++++++++++++++++++++++++++
  9698.  
  9699. >From Jonathan D Baumgartner <Jonathan.D.Baumgartner@unh.edu>
  9700. Date: 24 Feb 1994 18:24:47 GMT
  9701. Organization: Computing & Information Services, University of New Hampshire
  9702.  
  9703. In article <2kg76v$bei@u.cc.utah.edu> Dmitry Boldyrev,
  9704. dmitry@atlas.chem.utah.edu writes:
  9705. >Yeah, I know about the way of making such a font.. looks like it is the
  9706. >only
  9707. >solution I can think of. I've done the same way as Johnatan described,
  9708. but
  9709. >there iz a little problem. Suppose you want to show a password when you
  9710. >create
  9711. >a window.. How would you do it?
  9712. >like I want !!!!!! to be shown when the dialog appears.. they way you
  9713. >suggest
  9714. >it it won't work.
  9715.  
  9716. Um, you mean you want the password to show up as a series of !s before
  9717. anything is typed?  Like a default password or something?
  9718.  
  9719. Assuming that's what you mean, I just use GetDItem() and SetIText().  Get
  9720. a handle to the edit text field with GetDItem(), and then use SetIText()
  9721. to change the text to an appropriate number of !s.
  9722.  
  9723. (Appropriate number in this case would be the length of the actual
  9724. password.)
  9725.  
  9726. jon
  9727. --
  9728. Jonathan D. Baumgartner        Jonathan.D.Baumgartner@unh.edu 
  9729. Computing & Information Services, University of New Hampshire            
  9730.  
  9731.            "It's just a matter of opinion." -- Primus
  9732.  
  9733. +++++++++++++++++++++++++++
  9734.  
  9735. >From f8dy@access.netaxs.com (Mark Pilgrim)
  9736. Date: 24 Feb 1994 22:22:38 GMT
  9737. Organization: Net Access - Philadelphia's Internet Connection
  9738.  
  9739. Peter N Lewis (peter@ncrpda.curtin.edu.au) wrote:
  9740. : infosafe@panix.com (Tom Lipscomb) writes:
  9741.  
  9742. : >The easiest solution I came up with was to make my own font, which had
  9743. : >one character (a diamond) for all of the letters.  Use this font for
  9744. : >the edit text that they are typing the password in.
  9745.  
  9746. : Don't spaces show up though?  Last time I tried this, the spaces showed up
  9747. : even if your font didn't define the space character or even if you did,
  9748. : it would show up as a space.  This was a long time back, maybe its changed?
  9749. :    Peter.
  9750.  
  9751. Peter, you are correct.  Tom, the one (potential) problem with your method
  9752. is that one could copy the password to the clipboard and paste it somewhere
  9753. else in a different font -- especially a problem if the dialog box is
  9754. coming up with a password already there (in diamonds or bullets or bangs).
  9755.  
  9756. After much agonizing over this issue, I finally went with the "editable
  9757. text item outside the frame of the dialog" approach.  I did _not_ have a
  9758. second text item that mirrored the first one with bullets(/diamonds/bangs);
  9759. instead, I displayed a character count (similar to Compact Pro) which
  9760. updated with every keypress to the length of the editable text box.  (This
  9761. covers the situation of a user pasting in a password and/or cutting part of
  9762. it out, where the length of the password may change by more than +-1.)  And
  9763. I had checkboxes to hide/show the character count and hide/show the password
  9764. itself -- both of which should be saved a preferences and restored the next
  9765. time the user has to enter a password.
  9766.  
  9767. Of course, this doesn't solve the problem of having a password there when
  9768. the dialog box comes up, since you could just check "show password" and see
  9769. it. (:  But having a password there is an inherent security weakness.  I
  9770. have discovered the password to an Appletalk server in the Chooser because
  9771. the password was "there" but expressed in bullet characters (i.e. copying
  9772. and pasting just yields bullets).  Replacing one character at a time and
  9773. seeing if it was still the right password gave me the password in less than
  9774. a minute.  (Of course, I assumed standard character frequencies and the
  9775. password happened to be "tres", but it's still a bad assumption that just
  9776. because the dialog box contains bullet characters that the underlying
  9777. password is safe.)
  9778.  
  9779. --
  9780. Mark Pilgrim | f8dy@netaxs.com | Please do not worry the philosophers.
  9781. "I can't say enough about the importance of brevity."
  9782.  
  9783. +++++++++++++++++++++++++++
  9784.  
  9785. >From ez015670@hamlet.ucdavis.edu ()
  9786. Date: Fri, 25 Feb 1994 00:33:49 GMT
  9787. Organization: University of California, Davis
  9788.  
  9789. Mark Pilgrim (f8dy@access.netaxs.com) wrote:
  9790. : Peter N Lewis (peter@ncrpda.curtin.edu.au) wrote:
  9791. : : Don't spaces show up though?  Last time I tried this, the spaces showed up
  9792. : : even if your font didn't define the space character or even if you did,
  9793. : : it would show up as a space.  This was a long time back, maybe its changed?
  9794. : :    Peter.
  9795.  
  9796. : Peter, you are correct.  Tom, the one (potential) problem with your method
  9797.  
  9798. Another potential security problem that has not been addressed is the picking
  9799. up of the password at a much lower level.  I have made a program that
  9800. prints all the characters pressed to a file including passwords.  Maybe
  9801. through a jGNE filter one could remove the characters before other inits
  9802. can get a hold of them.
  9803.  
  9804. Bret Olmsted
  9805. olmsted@cs.ucdavis.edu
  9806.  
  9807.  
  9808.  
  9809. +++++++++++++++++++++++++++
  9810.  
  9811. >From scott.m.silver@dartmouth.edu (Scott M. Silver)
  9812. Date: 25 Feb 1994 03:28:06 GMT
  9813. Organization: Dartmouth College - Hanover, NH
  9814.  
  9815. In article <CLr88E.C7F@ucdavis.edu>
  9816. ez015670@hamlet.ucdavis.edu () writes:
  9817.  
  9818. > Another potential security problem that has not been addressed is the picking
  9819. > up of the password at a much lower level.  I have made a program that
  9820. > prints all the characters pressed to a file including passwords.  Maybe
  9821. > through a jGNE filter one could remove the characters before other inits
  9822. > can get a hold of them.
  9823.  
  9824. This sort of seems to be one of those things where if "the person can
  9825. get to the computer-locally, then your data is not safe".  (Unless it's
  9826. encrypted).  Anyone can patch every single trap, write a jGNE filter,
  9827. etc and figure out what your password is (or get a program to watch you
  9828. type it in).  Hell, they could video tape you typing it in.
  9829.  
  9830. Scott
  9831.  
  9832. ____________________________________________________________________
  9833. Scott Silver            Dartmouth College                Hanover, NH
  9834.  
  9835. +++++++++++++++++++++++++++
  9836.  
  9837. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  9838. Date: 24 Feb 1994 10:47:58 GMT
  9839. Organization: Royal Institute of Technology, Stockholm, Sweden
  9840.  
  9841. In <2kfrn9$d4v@mozz.unh.edu> Jonathan D Baumgartner <Jonathan.D.Baumgartner@unh.edu> writes:
  9842.  
  9843. >>The easiest solution I came up with was to make my own font, which had
  9844. >>one character (a diamond) for all of the letters.  Use this font for
  9845. >>the edit text that they are typing the password in.
  9846.  
  9847. >That's an interesting solution; wish I'd thought of that earlier :-)
  9848.  
  9849. Because fonts in applications are a bad idea (for a number
  9850. of Font Manager reasons)
  9851.  
  9852. What I do is I patch the QuickDraw text measurement and text
  9853. drawing bottlenecks to measure a string of bullets instead of
  9854. the real string.
  9855.  
  9856. Cheers,
  9857.  
  9858.                     / h+
  9859. -- 
  9860.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  9861.     Not speaking for the Microsoft Corporation.
  9862.  
  9863. +++++++++++++++++++++++++++
  9864.  
  9865. >From infosafe@panix.com (Tom Lipscomb)
  9866. Date: 25 Feb 1994 01:11:10 -0500
  9867. Organization: PANIX Public Access Internet and Unix, NYC
  9868.  
  9869. In article <2kg799$bei@u.cc.utah.edu>,
  9870. Dmitry Boldyrev  <dmitry@atlas.chem.utah.edu> wrote:
  9871. >In article <2kenne$rku@panix2.panix.com> Tom Lipscomb, infosafe@panix.com
  9872. >writes:
  9873. >>The easiest solution I came up with was to make my own font, which had
  9874. >>one character (a diamond) for all of the letters.  Use this font for
  9875. >>the edit text that they are typing the password in.
  9876. >>
  9877. >>Cheers,
  9878. >>Bradford Smith
  9879. >
  9880. >A little problem too.
  9881. >How would you do it if you have two editing items?
  9882. >When you change the font, it will make all TE items the same font.. ?
  9883. >Thanks
  9884. >
  9885. >Dmitry.
  9886.  
  9887. For static text I made them User Items that drew the appropriate text in
  9888. Chicago.  For the field where they typed the name, I set the font to 
  9889. be Geneva, or something.  For the field where I put the password, I set the
  9890. font to be .pwd font (or whatever it was).  It's not the most secure 
  9891. method; as lots of people pointed out, you can copy it to another field
  9892. and see what the text is.
  9893.  
  9894. For me this was not a concern, though.  The person typed in the name and
  9895. pwd, it was accepted or rejected, and they moved on.  The only person who
  9896. could have copied the text to another app was the person who just typed 
  9897. it in -- not a security risk.
  9898.  
  9899. As for writing an init to catch the keystrokes -- anyone know how to stop it?
  9900.  
  9901. Cheers,
  9902. Bradford
  9903.  
  9904. +++++++++++++++++++++++++++
  9905.  
  9906. >From Jim.Matthews@dartmouth.edu (Jim Matthews)
  9907. Date: 25 Feb 1994 14:11:52 GMT
  9908. Organization: Dartmouth College
  9909.  
  9910. In article <2ki0ku$pir@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte)
  9911. wrote:
  9912.  
  9913. > What I do is I patch the QuickDraw text measurement and text
  9914. > drawing bottlenecks to measure a string of bullets instead of
  9915. > the real string.
  9916.  
  9917. I tried that once but found it difficult to tell when StdText and StdMeas
  9918. were being called for the password, as opposed to anything else in the
  9919. dialog.  Is there a sure-fire way to do this?
  9920.  
  9921. Jim Matthews
  9922. Dartmouth Software Development
  9923.  
  9924. +++++++++++++++++++++++++++
  9925.  
  9926. >From Mark.R.Valence@dartmouth.edu (kurash@dartmouth.edu)
  9927. Date: 25 Feb 1994 18:37:55 GMT
  9928. Organization: Dartmouth College, Hanover, NH
  9929.  
  9930. In article <Jim.Matthews-250294091049@ishmael.dartmouth.edu>
  9931. Jim.Matthews@dartmouth.edu (Jim Matthews) writes:
  9932. > In article <2ki0ku$pir@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte)
  9933. > wrote:
  9934. > > What I do is I patch the QuickDraw text measurement and text
  9935. > > drawing bottlenecks to measure a string of bullets instead of
  9936. > > the real string.
  9937. > I tried that once but found it difficult to tell when StdText and StdMeas
  9938. > were being called for the password, as opposed to anything else in the
  9939. > dialog.  Is there a sure-fire way to do this?
  9940.  
  9941. I tried patching the screen driver and watched for the proper bit
  9942. pattern of the real password characters, then replaced the bits with a
  9943. bullet pattern.  I never did get that to work... ;-)
  9944.  
  9945. There are two main weaknesses of using a "bullet font" (or the StdText
  9946. method) to hide a password in a dialog box edittext item.  First,
  9947. anyone can grab the password by choosing Copy from the Edit menu (under
  9948. Sys7).  This is not an issue unless the user has a habit of typing a
  9949. password and leaving the dialog on the screen.
  9950.  
  9951. The more important drawback is that it is difficult to handle two-byte
  9952. character sets.  Because the font would be script specific, extra
  9953. "bullet" characters would be emitted.
  9954.  
  9955. The source below solves the password-in-a-dialog problem by filtering
  9956. the event stream and modifying the proper key-down events.  It keeps a
  9957. private copy of the password. Although this implementation does not
  9958. support multibyte character sets, it could be modified to do so easily
  9959. (and in fact I am going to have to do this eventually myself).
  9960.  
  9961. The PassFilter routine uses another dialog filter routine that handles
  9962. the non-password related stuff (OK and Cancel keyboard equivalents,
  9963. etc.)  You need to write this y'self.
  9964.  
  9965. On a side note, I always liked the way the original StuffIt (I think)
  9966. handled the archive password.  It just changed the font size to
  9967. something like 2, and used PICTs for the "static text" (there were no
  9968. non-password edit text items).  Cute.
  9969.  
  9970. Mark.
  9971.  
  9972. - --------------------------------------------------------------------
  9973. "On the Internet, nobody knows you're a dog."   Ice Peak Form Mice Elf
  9974.                     -- cartoon in New Yorker
  9975.  
  9976.  
  9977. /*
  9978.  *    (c)1994 Mark Valence
  9979.  *
  9980.  *    Permission to use and alter this source is
  9981.  *    granted, provided that you do not transmit
  9982.  *    the resulting password in cleartext over a
  9983.  *    network (unless required by the protocol).
  9984.  */
  9985.  
  9986. #include <types.h>
  9987. #include <memory.h>
  9988. #include <events.h>
  9989. #include <windows.h>
  9990. #include <dialogs.h>
  9991. #include <controls.h>
  9992.  
  9993. /*
  9994.  * example of usage:
  9995.  *
  9996.  *    PassData pdata;
  9997.  *    Str255 mypass;
  9998.  *
  9999.  *    ...
  10000.  *    pdata.passitem = MY_PASSWORD_ITEM;
  10001.  *    pdata.passmax = 8;
  10002.  *    pdata.bullet = '*';
  10003.  *    pdata.password = mypass;
  10004.  *    *mypass = 0;
  10005.  *    SetWRefCon(dialog, (long)&pdata);
  10006.  *    ModalDialog((ProcPtr)PassFilter, &item);
  10007.  *    ...
  10008.  */
  10009.  
  10010. /*
  10011.  * a pointer to this structure is placed in the refCon
  10012.  * of the dialog box that contains the password item.
  10013.  * the buffer that 'password' points to must be at
  10014.  * least 'passmax'+1 bytes (one byte for the length),
  10015.  * and must initially be zero-length.
  10016.  */
  10017. typedef struct t_passdata {
  10018.     short passitem;        /* dialog item number of password text */
  10019.     short passmax;        /* maximum length of password */
  10020.     char bullet;        /* special character to use */
  10021.     StringPtr password;    /* pointer to a buffer for the real password */
  10022. } PassData;
  10023.  
  10024.  
  10025. /*
  10026.  * this routine must be linked in from another source
  10027.  * it is responsible for handling special keystrokes
  10028.  * such as <return>, <enter>, <escape>, Cmd-., etc.
  10029.  * UpdtFilter also handles window update events for
  10030.  * application windows and the Edit menu command keys.
  10031.  */
  10032. pascal Boolean UpdtFilter (DialogPtr dialog, EventRecord *event, short
  10033. *item);
  10034.  
  10035. /*
  10036.  * these routines are included below for completeness
  10037.  */
  10038. char *pstrdel (unsigned char *s, int ix, int len);
  10039. char *pstrins (unsigned char *s, unsigned char c, int ix);
  10040.  
  10041.  
  10042. pascal Boolean
  10043. PassFilter (DialogPtr dialog, EventRecord *event, short *item)
  10044. {
  10045.     PassData *passp;
  10046.     short selStart, selEnd;
  10047.     unsigned char ch;
  10048.     Str255 hold;
  10049.     short kind;
  10050.     Handle h;
  10051.     Rect r;
  10052.  
  10053.     /* take care of return, enter, cmd-.,
  10054.      * escape, updates, Edit menu, etc.
  10055.      */
  10056.     if (UpdtFilter(dialog, event, item))
  10057.         return(true);
  10058.  
  10059.     passp = (PassData *)GetWRefCon(dialog);
  10060.     if (!(event->modifiers & cmdKey)
  10061.         && (event->what == keyDown || event->what == autoKey)
  10062.         && (((DialogPeek)dialog)->editField == (passp->passitem - 1)))
  10063.     {
  10064.         ch = event->message & charCodeMask;
  10065.         selStart = (**(((DialogPeek)dialog)->textH)).selStart;
  10066.         selEnd = (**(((DialogPeek)dialog)->textH)).selEnd;
  10067.  
  10068.         switch (ch) {
  10069.         case 0x08:    /* backspace */
  10070.             if (selEnd != selStart)
  10071.                 pstrdel(passp->password, selStart + 1, selEnd - selStart);
  10072.             else if (selStart > 0)
  10073.                 pstrdel(passp->password, selStart, 1);
  10074.             break;
  10075.  
  10076.         case 0x09:    /* tab */
  10077.         case 0x1C:    /* left arrow */
  10078.         case 0x1D:    /* right arrow */
  10079.         case 0x1E:    /* up arrow */
  10080.         case 0x1F:    /* down arrow */
  10081.             break;
  10082.  
  10083.         default:
  10084.             BlockMove(passp->password, hold, sizeof(hold));
  10085.             pstrdel(hold, selStart + 1, selEnd - selStart);
  10086.             pstrins(hold, ch, selStart + 1);
  10087.             if (*hold > passp->passmax) {
  10088.                 event->what = nullEvent;
  10089.                 SysBeep(1);
  10090.             } else {
  10091.                 BlockMove(hold, passp->password, *hold + 1);
  10092.                 event->message &= 0xFFFFFF00;
  10093.                 event->message |= passp->bullet;
  10094.             }
  10095.             break;
  10096.         }
  10097.  
  10098.         GetDItem(dialog, ok, &kind, &h, &r);
  10099.         HiliteControl((ControlHandle)h, (*passp->password ? 0 : 255));
  10100.     }
  10101.     return(false);
  10102. }
  10103.  
  10104. char *
  10105. pstrdel (unsigned char *s, int ix, int len)
  10106. {
  10107.     int last;
  10108.  
  10109.     if (len == 0 || ix > *s)
  10110.         return(s);
  10111.  
  10112.     last = ix + len;
  10113.     if (last > *s) {
  10114.         *s = ix - 1;
  10115.     } else {
  10116.         BlockMove(&s[last], &s[ix], *s - last + 1);
  10117.         *s -= len;
  10118.     }
  10119.     return(s);
  10120. }
  10121.  
  10122. char *
  10123. pstrins (unsigned char *s, unsigned char c, int ix)
  10124. {
  10125.     if (*s < 0x00FF)
  10126.         (*s)++;
  10127.     BlockMove(&s[ix], &s[ix + 1], *s - ix);
  10128.     s[ix] = c;
  10129.     return(s);
  10130. }
  10131.  
  10132.  
  10133. +++++++++++++++++++++++++++
  10134.  
  10135. >From kjohnso@nyx10.cs.du.edu (Kai)
  10136. Date: Fri, 4 Mar 94 21:26:04 GMT
  10137. Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
  10138.  
  10139. In article <2klgi3$36o@dartvax.dartmouth.edu>,
  10140. kurash@dartmouth.edu <Mark.R.Valence@dartmouth.edu> wrote:
  10141. >In article <Jim.Matthews-250294091049@ishmael.dartmouth.edu>
  10142. >Jim.Matthews@dartmouth.edu (Jim Matthews) writes:
  10143. >
  10144. >There are two main weaknesses of using a "bullet font" (or the StdText
  10145. >method) to hide a password in a dialog box edittext item.  First,
  10146. >anyone can grab the password by choosing Copy from the Edit menu (under
  10147. >Sys7).  This is not an issue unless the user has a habit of typing a
  10148. >password and leaving the dialog on the screen.
  10149. >
  10150. >The more important drawback is that it is difficult to handle two-byte
  10151. >character sets.  Because the font would be script specific, extra
  10152. >"bullet" characters would be emitted.
  10153. >
  10154. >The source below solves the password-in-a-dialog problem by filtering
  10155. >the event stream and modifying the proper key-down events.  It keeps a
  10156. >private copy of the password. Although this implementation does not
  10157. >support multibyte character sets, it could be modified to do so easily
  10158. >(and in fact I am going to have to do this eventually myself).
  10159. >
  10160. >[source deleted...]
  10161.  
  10162. You can do the same trick and support all the standard TextEdit things
  10163. by putting a hidden TE item offscreen and rerouting key events to it.
  10164. Just keep the selections in the two items in sync, and match the number
  10165. of bullets in the visible item to the hidden one.
  10166.  
  10167. The user can copy the password all they want, but they just get bullets.
  10168.  
  10169. I think this is how the sample code in the H/I notes from Apple works...
  10170.  
  10171. Oh, if you're doing passwords, you should have a look at the note about
  10172. them, there are some standard ways for handling all the clicks and key
  10173. presses.
  10174.  
  10175. I can probably find both the H/I note and the sample code if you but me
  10176. about it.
  10177.  
  10178. -Kai
  10179.  
  10180. +++++++++++++++++++++++++++
  10181.  
  10182. >From moofster@world.std.com (A Happy Dog-Cow)
  10183. Date: Sun, 6 Mar 1994 05:36:58 GMT
  10184. Organization: The Nest of the Moofster
  10185.  
  10186. Sheesh!  All of this talk of patching traps & weirdo fonts to just make
  10187. a password entry screen!  Programmers should be on guard against
  10188. innapropriate over-engineering!!  Sheesh!  Just make a ModalDialogFIlter
  10189. procedure, intercept the update routine for the item(s) in question,
  10190. and voila.  Patching traps or coming up with exotic fonts to perform
  10191. this is unnecessary!
  10192.  
  10193. Robert M. Seretny, Armesti Research,
  10194. (Macintosh/SCSI guru for short-term hire; email moofster@world.std.com)
  10195.  
  10196.  
  10197. +++++++++++++++++++++++++++
  10198.  
  10199. >From danprice@delphi.com
  10200. Date: Mon, 7 Mar 94 18:55:47 -0500
  10201. Organization: Delphi (info@delphi.com email, 800-695-4005 voice)
  10202.  
  10203.  
  10204. I dunno, I wrote a short routine for a friend in a comp/sci course who wanted
  10205. to impress his teacher.  Basically, I set up a dialog with 12 buttons, in
  10206. a numeric keypad arrangement.  The things that's neat about this is that,
  10207. unless the "hacker" is extremely clever, he won't be able to use a filter
  10208. (sorry, not a filter) a trap patch to intercept the passcode, as the
  10209. difficulty of figuring which part of the screen clicked is fairly high.
  10210.  
  10211. Also, I thought about randomly scrambling the buttons in the dialog, to
  10212. make this _even_ harder, as well as to foil those with binoculars and such.
  10213.  
  10214. I think this whole password thing is overkill....
  10215.     -dp
  10216.  
  10217. ---------------------------
  10218.  
  10219. >From python@jhunix.hcf.jhu.edu (Bryan Arntson)
  10220. Subject: Permanent front windows...
  10221. Date: 3 Mar 1994 17:53:33 -0500
  10222. Organization: Homewood Academic Computing, Johns Hopkins University, Baltimore, Md, USA
  10223.  
  10224. I apologize for not knowing what these windows are called, but how do I
  10225. create those windows that are ALWAYS in the front.  They look like little
  10226. fake windows.  They have B&W window titles, that are about 10 pixels high,
  10227. and then the window below them.  What are these called?  And most
  10228. importantly, HOW DO I CREATE ONE?  Could someone post, or send me, a short
  10229. code on the subject?
  10230.  
  10231. Thanks in advance,
  10232.  
  10233. Bryan
  10234. python@jhunix.hcf.jhu.edu
  10235.  
  10236.  
  10237. +++++++++++++++++++++++++++
  10238.  
  10239. >From troy@i-link.com (Troy Gaul)
  10240. Date: 3 Mar 1994 23:24:53 -0600
  10241. Organization: I-Link, Ltd., Des Moines, IA
  10242.  
  10243. In article <2l5ppdINN5qk@jhunix.hcf.jhu.edu>,
  10244. Bryan Arntson <python@jhunix.hcf.jhu.edu> wrote:
  10245. >I apologize for not knowing what these windows are called, but how do I
  10246. >create those windows that are ALWAYS in the front.  
  10247.  
  10248. There are several names that are used, including 'Utility Window', 'Tool
  10249. Window', 'Palette', 'Windoid', 'Floating Window', and 'Floater'. 
  10250.  
  10251. >They look like little
  10252. >fake windows.  They have B&W window titles, that are about 10 pixels high,
  10253. >and then the window below them.  
  10254.  
  10255. They don't _have_ to have a B&W window title. The only reason that I can
  10256. think of that many of them are B&W is that the programmers didn't know
  10257. about the Infinity Windoid WDEF (which, it happens, I wrote), which gives
  10258. you a System 7-style coloring scheme (but is also compatible with System 6).
  10259. It gives these to you for free, as it is freeware, and worry-free (it's been
  10260. well tested, and the source is included).
  10261.  
  10262. >What are these called?  And most
  10263. >importantly, HOW DO I CREATE ONE?  Could someone post, or send me, a short
  10264. >code on the subject?
  10265.  
  10266. You can make a window with this type of a titlebar by getting the Infinity
  10267. Windoid WDEF from the anonymous FTP site:
  10268.  
  10269.     ftp://ftp.i-link.com/pub/infsys/
  10270.  
  10271. This WDEF does not help you make the window float on top of the others,
  10272. however. To do this, you need a floating window library. There was one
  10273. included with Develop 15, and updated code was included with Develop 16.
  10274. You can pick up the latest version of that code, along with the text of
  10275. the article (through an arrangement I make with Apple), in the same place.
  10276.  
  10277. _troy
  10278.  
  10279. -- 
  10280. //////// //////   Troy Gaul                            t-gaul@i-link.com   //
  10281.   //    //       I-Link, Ltd.                                             //
  10282.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)              //
  10283. //    ////// __________________________________________________________ //
  10284.  
  10285. +++++++++++++++++++++++++++
  10286.  
  10287. >From kurisuto@chopin.udel.edu (Sean J. Crist)
  10288. Date: 4 Mar 1994 11:37:41 -0500
  10289. Organization: University of Delaware
  10290.  
  10291. >This WDEF does not help you make the window float on top of the others,
  10292. >however. To do this, you need a floating window library. There was one
  10293. >included with Develop 15, and updated code was included with Develop 16.
  10294. >You can pick up the latest version of that code, along with the text of
  10295. >the article (through an arrangement I make with Apple), in the same place.
  10296.  
  10297. Or, for that matter, you could just write your own routines to do this. 
  10298. This only took me a few hours to do.  Basically, you've got to rewrite the
  10299. top level of the window manager.  A good start is to write a routine that
  10300. acts like SelectWindow (calling ShowHide and HiliteWindow) except that it
  10301. leaves your Palette window in front.  Then go through your code and do a
  10302. global search-and-replace to change SelectWindow to the name of your
  10303. replacement routine.  If you can get that much working properly, that's
  10304. 90% of the game.
  10305.  
  10306. If there's interest, I can post my code; it's pretty complicated, though,
  10307. because I'm doing a lot more than just supporting floating palettes. 
  10308. Rather than keep a million WindowPtr's to everything (which is messy when
  10309. your application allows the user to open any number of instances of a
  10310. particular type of window), I keep information about the window in a
  10311. handle stored in the window's RefCon.  Then when I need window number X of
  10312. type Y, I call one of my routines to quickly search through the linked
  10313. list of windows to try to find a match.  I can clean up this code a little
  10314. and post it if there's interest.
  10315.  
  10316. --Sean (kurisuto@chopin.udel.edu)
  10317.  
  10318.   \/ __ __    _\_   |  If restaurants were named as gay organizations are,
  10319.  ---  |  |    \ /   |  "McDonald's" would be called "Meat, Bread, Vegetables,
  10320.   _| ,| ,|   -----  |  Beverages, Condiments, and Friends" (MBVBCF for short).
  10321.   _| ,| ,|    [_]   |--------------------------------------------------------
  10322.    |  |  |    [_]   |  Finger this account for a copy of the Bill of Rights.
  10323.  
  10324. ---------------------------
  10325.  
  10326. >From andersw@hum.gu.se (Anders Wahlin)
  10327. Subject: Preference file question!
  10328. Date: Fri, 4 Mar 1994 08:03:28 GMT
  10329. Organization: Hum Fak:s Dataservice
  10330.  
  10331. Almost every program has a preference file. I have twoo very simple
  10332. questions about this. 
  10333.  
  10334. 1•    Is it "wrong" to have a resource file as a preference file?
  10335.  
  10336. 2•    How can I create an icon on my preference file, within the program?
  10337.  
  10338. Thanks!
  10339.  
  10340. -- 
  10341. Anders Wahlin
  10342. andersw@hum.gu.se
  10343.  
  10344. +++++++++++++++++++++++++++
  10345.  
  10346. >From rmah@panix.com (Robert S. Mah)
  10347. Date: Fri, 04 Mar 1994 04:52:40 -0500
  10348. Organization: One Step Beyond
  10349.  
  10350. andersw@hum.gu.se (Anders Wahlin) wrote:
  10351.  
  10352. > Almost every program has a preference file. I have twoo very simple
  10353. > questions about this. 
  10354. > 1    Is it "wrong" to have a resource file as a preference file?
  10355.  
  10356. No, many programs use resources to store their prefs.  The only drawback is
  10357. that the file is no longer platform independent.  I've often thought of
  10358. using a text file to store prefs.
  10359.  
  10360.  
  10361. > 2    How can I create an icon on my preference file, within the program?
  10362.  
  10363. Simply add an entry into your BNDL resource with associated FREF and
  10364. ICN#/icl/ics resources. 
  10365.  
  10366. However, please think about using the standard 'pref' file type.  The
  10367. finder will give it a nice prefs style icon and people's preferences folder
  10368. will open just a bit faster.  Now if everyone did this...
  10369.  
  10370. Cheers,
  10371. Rob
  10372. ________________________________________________________________________
  10373.  Robert S. Mah              One Step Beyond              rmah@panix.com
  10374.  
  10375. +++++++++++++++++++++++++++
  10376.  
  10377. >From Lars.Farm@nts.mh.se (Lars Farm)
  10378. Date: Fri, 04 Mar 1994 11:33:02 +0100
  10379. Organization: Mid Sweden University
  10380.  
  10381. In article <andersw-040394090400@bigmac.hds.gu.se>, andersw@hum.gu.se
  10382. (Anders Wahlin) wrote:
  10383.  
  10384. > 1•    Is it "wrong" to have a resource file as a preference file?
  10385.  
  10386. No. It's common practice.
  10387.  
  10388. > 2•    How can I create an icon on my preference file, within the program?
  10389.  
  10390. Set the file type to 'pref'.
  10391.  
  10392. Lars
  10393.  
  10394. -- 
  10395. Lars.Farm@nts.mh.se
  10396.  
  10397. +++++++++++++++++++++++++++
  10398.  
  10399. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  10400. Date: 5 Mar 1994 21:14:20 +0800
  10401. Organization: NCRPDA, Curtin University
  10402.  
  10403. rmah@panix.com (Robert S. Mah) writes:
  10404.  
  10405. >However, please think about using the standard 'pref' file type.  The
  10406. >finder will give it a nice prefs style icon and people's preferences folder
  10407. >will open just a bit faster.  Now if everyone did this...
  10408.  
  10409. Do this - it's much nicer.  I used to do it the other way with a BNDL and
  10410. icon for the prefs file, but the Preferences folder is full up with
  10411. thousands of different icons, it's just a mess.  So use the 'pref' file
  10412. type, and don't worry about designing an icon, and life will be good.
  10413.    Peter.
  10414. -- 
  10415. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  10416.  
  10417. +++++++++++++++++++++++++++
  10418.  
  10419. >From perm@csd.uu.se (Per Mildner)
  10420. Date: 11 Mar 1994 14:56:23 GMT
  10421. Organization: Computing Science Dept.,Uppsala University, Sweden
  10422.  
  10423.  
  10424. Several people have suggested using the 'pref' file type for
  10425. preference files.  There is one problem with this, this is the type
  10426. for the finder prefs.  Most people thinks this is a good thing as this
  10427. automagically gives the pref file a good icon, but the people
  10428. suggesting this are not likely to use balloon help in the finder :-)
  10429. If you use the pref file you better add some balloon info in your pref
  10430. file too. (Another potential problem might be with EasyOpen or
  10431. whatever which I have not used).
  10432. Regards,
  10433. --
  10434. Per Mildner            Per.Mildner@CSD.UU.SE
  10435. Computing Science Dept.        tel: +46 18 181049
  10436. Uppsala University, Sweden    fax: +46 18 521270
  10437.  
  10438. +++++++++++++++++++++++++++
  10439.  
  10440. >From t-gaul@i-link.com (Troy Gaul)
  10441. Date: Fri, 11 Mar 1994 12:35:25 -0600
  10442. Organization: I-Link, Ltd.
  10443.  
  10444. In article <PERM.94Mar11155623@groucho.csd.uu.se>, perm@csd.uu.se (Per
  10445. Mildner) wrote:
  10446.  
  10447. > Several people have suggested using the 'pref' file type for
  10448. > preference files.  There is one problem with this, this is the type
  10449. > for the finder prefs.  Most people thinks this is a good thing as this
  10450. > automagically gives the pref file a good icon, but the people
  10451. > suggesting this are not likely to use balloon help in the finder :-)
  10452. > If you use the pref file you better add some balloon info in your pref
  10453. > file too. 
  10454.  
  10455. I really don't think this is a big issue against using that as a file type.
  10456. Besides, I have several other pieces of Apple software (the Apple Modem
  10457. Tool was the one I saw when I checked this out) that also do the same
  10458. thing.
  10459.  
  10460. > (Another potential problem might be with EasyOpen or
  10461. > whatever which I have not used).
  10462.  
  10463. I don't see where this would be a problem. Actually, quite the opposite is
  10464. true. If you have the resources for Easy Open in your application, then you
  10465. can describe the preferences file with a 'kind' resource as 'MyApplication
  10466. preferences', and this would appear in the Finder names lists of the
  10467. preferences folder (or the get info box).  
  10468.  
  10469. Easy Open uses the creator of the file to determine its labeling,
  10470. apparently, the Balloon help in the Finder doesn't look at the creator of
  10471. the file when the cursor's pointed at a 'pref' file as it should.
  10472.  
  10473. I've taken the advice to use 'pref' as the file type and to NOT include an
  10474. icon for that type to heart.  I'm doing it in most of my own programming
  10475. projects now.
  10476.  
  10477. _troy
  10478. //////// //////___Troy Gaul_________________________t-gaul@i-link.com__ //
  10479.   //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
  10480.  //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
  10481. //    //////________________________________________________________ //
  10482.  
  10483. ---------------------------
  10484.  
  10485. >From pope@imv.aau.dk (Povl H. Pedersen)
  10486. Subject: Reading PICT files != 72 dpi. How ?
  10487. Date: 26 Feb 1994 16:01:21 GMT
  10488. Organization: Information and Media Science, Aarhus University, DENMARK
  10489.  
  10490. I am working on a small custom image modifying program, and it will have 
  10491. to load in PICT files created in other applications.
  10492.  
  10493. I have managed to steal some code that will rwad/write PICT files, but my 
  10494. problem now is, that the end user somethimes generates PICTs in a better 
  10495. resolution than 72 dpi. When he reads them in, they are shrinked to keep 
  10496. size as the original, and he then loses information.
  10497.  
  10498. How do I read in PICT files with all osrts of resolution, handle them as 
  10499. pixel-by-pixel images, and then finally write them back with their 
  10500. original resolution info ?
  10501.  
  10502. thanks in advance,
  10503.  
  10504. - -
  10505. Povl H. Pedersen  -  Macintosh Consultant and Programmer
  10506. pope@imv.aau.dk (preferred)  /  povlphp@uts.uni-c.dk
  10507.  
  10508. "Macintosh...for those who can see through Windows!"
  10509.  
  10510. +++++++++++++++++++++++++++
  10511.  
  10512. >From pope@imv.aau.dk (Povl H. Pedersen)
  10513. Date: 28 Feb 1994 18:16:17 GMT
  10514. Organization: Information and Media Science, Aarhus University, DENMARK
  10515.  
  10516. I wanted to know how I could read in a PICT in a higher than 72dpi 
  10517. resolution, and keep every single pixel. I tried the net, as it is usual 
  10518. a good fast reference manual ;^)
  10519.  
  10520. The net did not want to answer me, so I did spend some time, and found a 
  10521. working way. I am using information on page 17-24 of Inside Macintosh 
  10522. volume VI. This info is not documented in any headers anywhere, but I 
  10523. suppose it is safe to use.
  10524.  
  10525. (Now, why has Apple not given us routines to read/write PICT files ? They 
  10526. should be a natural part of the toolbox. Just like some way to get a 
  10527. PicHandle from a pixmap).
  10528.  
  10529. My ugly code is enclosed below. I did slight editing after copy/pasting, so
  10530. it may contain a few syntax errors. My routine allocates a new offscreen 
  10531. GWorld, and reads the picture in here. Only minimum level of error 
  10532. checking is done. The application where this is used will not be run on 
  10533. large images on machines with less than 32-64 MB RAM. So memory is no 
  10534. problem. This is one reason I make the offscreen pixmap 32 bits instead 
  10535. of using the information from the file. Another reason is, that I parse 
  10536. all pixels in a loop that expects 32bit pixmap.
  10537.  
  10538. Disclaimer: This code is guaranteed to be incompatible with at least one 
  10539. version of one Microsoft product. Not necesarily now, but then in the 
  10540. future. Don't blame me. Blame the guilty ones.
  10541.  
  10542. Povl
  10543.  
  10544. - -----------------------------
  10545.  
  10546. // structure not defined anywhere. Contents just listed in IM VI, page 17-24
  10547. typedef struct {
  10548.     unsigned short  picSize;
  10549.     Rect            picFrame;
  10550.     // Now comes the header as displayed in IM VI, but not defined in any headers
  10551.     short           s1;             // = 0x0011 for special resolution
  10552.     short           s2;             // = 0x02FF
  10553.     short           HeaderOp;       // Opcode for PICT command. 0x0C00 = header
  10554.     short           version;        // = -2 for extended version 2 pict file
  10555.     short           reserved;
  10556.     Fixed           hRes;           // horizontal resolution
  10557.     Fixed           vRes;           // vertical resolution
  10558.     Rect            srcRect;        // Native source rectangle
  10559.     // More stuff follows but is ignored
  10560. } myVersion2PICTHeaderT;
  10561.  
  10562. static short gPICT_FILE_RESNUM;
  10563.  
  10564. // Quickdraw bottleneck routine to do the hard work
  10565. pascal void GetPICTData( Ptr dataPtr, short byteCount )
  10566. {
  10567.     long    longCount;
  10568.     
  10569.     longCount = byteCount;
  10570.     err = FSRead( gPICT_FILE_RESNUM, &longCount, dataPtr );
  10571. }
  10572.  
  10573. // This routine takes the following parametres:
  10574. // p:        a pointer to a GWorldPtr. On exit it will point to a new GWorld.
  10575. // filespec: FSSpec pointer that identifies the PICT file to read.
  10576.  
  10577. void getPICTFile( GWorldPtr *p, FSSpec *fileSpec)
  10578. {
  10579.     QDProcsPtr  savedProcs;
  10580.     CQDProcs    myProcs;
  10581.     GDHandle    gdh;
  10582.     CGrafPtr    port;
  10583.     PicHandle   thePic = nil;
  10584.     long        longCount;
  10585.     short       h, w;
  10586.     Rect        r,gr;
  10587.  
  10588.     PictInfo    pinfo;
  10589.  
  10590.     Fixed       vRes, hRes;     // horizontal/vertical resolutions
  10591.     myVersion2PICTHeaderT myPICTheader;
  10592.  
  10593.     *p = nil;        // lazy way to return error
  10594.     
  10595.     // Open file and skip old MacPaint header
  10596.     err = FSpOpenDF( fileSpec, fsRdPerm, &gPICT_FILE_RESNUM );
  10597.     SetFPos( gPICT_FILE_RESNUM, fsFromStart, 512);  // skip header
  10598.  
  10599.     // clear my header.
  10600.     memset( &myPICTheader, 0, sizeof(myPICTheader) );
  10601.     
  10602.     // Get the IM VI documented header
  10603.     longCount = sizeof( myPICTheader );
  10604.     err = FSRead( gPICT_FILE_RESNUM, &longCount, &myPICTheader );
  10605.     if (err != noErr) {
  10606.         TellUser( "Unpected End-of-File. Replace user and try again");
  10607.         return;
  10608.     }
  10609.     
  10610.     // Test if we have an extendended version 2 pict header
  10611.     if ( myPICTheader.s1 == 0x0011 && myPICTheader.s2 == 0x02FF && 
  10612.          myPICTheader.HeaderOp == 0x0C00 && myPICTheader.version == -2) {
  10613.     
  10614.         // Now we have a PICTure of another resolution
  10615.         
  10616.         hRes = myPICTheader.hRes;
  10617.         vRes = myPICTheader.vRes;
  10618.     }
  10619.     else
  10620.         hRes = vRes = Long2Fix( 72 );       // default resolution
  10621.  
  10622.     // skip back to header again, loading pict should start at pos=512
  10623.     SetFPos( gPICT_FILE_RESNUM, fsFromStart, 512);
  10624.     // Get room for the real header and read it
  10625.     thePic = (PicHandle) NewHandle(sizeof(Picture));
  10626.  
  10627.     longCount = sizeof( Picture );
  10628.     FSRead( gPICT_FILE_RESNUM, &longCount, (Ptr) *thePic );
  10629.     
  10630.     // different resolution, use the info from our version 2 extended header
  10631.     if (hRes != Long2Fix( 72 )) {
  10632.         w = myPICTheader.srcRect.right - myPICTheader.srcRect.left;
  10633.         h = myPICTheader.srcRect.bottom - myPICTheader.srcRect.top;
  10634.         r = myPICTheader.srcRect;
  10635.     }
  10636.     else {    // just use the data the old way
  10637.         w = (**thePic).picFrame.right;
  10638.         h = (**thePic).picFrame.bottom;
  10639.         r = (**thePic).picFrame;
  10640.     }
  10641.     
  10642.     // Now that we have the header, we know which size to make our offscreen buffer
  10643.     GetGWorld( &port, &gdh );
  10644.     
  10645.     SetRect( &gr, 0, 0, w, h );
  10646.     err = NewGWorld( p, 32, &gr, (CTabHandle) 0, (GDHandle) 0, 0 );
  10647.     if (err != noErr)
  10648.         DoCrashTheMachineAndAnnoyTheEndUser();
  10649.  
  10650.     SetGWorld( *p, nil );
  10651.     
  10652.     // Set our resolution. This makes sure the usual save routine will 
  10653.     // write it back for whatever DPI we use.
  10654.     (*p->portPixMap)->vRes = vRes;
  10655.     (*p->portPixMap)->hRes = hRes;
  10656.     
  10657.     // SetStdCProcs
  10658.     SetStdCProcs( &myProcs );
  10659.     myProcs.getPicProc = GetPICTData;
  10660.     savedProcs = ((GrafPtr) p)->grafProcs;
  10661.     ((CGrafPtr) p)->grafProcs = &myProcs;
  10662.     // this line does the real work
  10663.     DrawPicture( thePic, &r );
  10664.     
  10665.     SetGWorld( port, gdh ); 
  10666.  
  10667.     FSClose( gPICT_FILE_RESNUM );
  10668.     DisposHandle( (Handle) thePic );
  10669.     ((GrafPtr) p)->grafProcs = savedProcs;
  10670. }
  10671.  
  10672. - -
  10673. Povl H. Pedersen  -  Macintosh Consultant and Programmer (For hire).
  10674. System Administrator at the Aarhus Engineering School
  10675. pope@imv.aau.dk (preferred)  /  povlphp@uts.uni-c.dk
  10676.  
  10677. "Macintosh...for those who can see through Windows!"
  10678.  
  10679. ---------------------------
  10680.  
  10681. >From temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple)
  10682. Subject: Resources on PowerPC
  10683. Date: Fri, 11 Mar 1994 19:56:23 GMT
  10684. Organization: Naval Research Laboratory
  10685.  
  10686. There is an issue I have a little trouble with: it is my understanding
  10687. that Native applications on the Power Macintosh will not use resources
  10688. (or the resource fork.). What does this mean for programmers that are
  10689. used to ResEdit for creating/editing resources, whose code points to
  10690. reusable resources, etc? Will this feature of Mac programming simply
  10691. cease to exist when writing Native RISC applications or is there an
  10692. alternative approach that will treat part of the DATA fork on PPC Macs
  10693. as editable, callable, reusable resources that a new version of ResEdit
  10694. (DataEdit??) will able to work with?
  10695.  
  10696. Ideas?
  10697.  
  10698.  
  10699. +++++++++++++++++++++++++++
  10700.  
  10701. >From minnis@cobaf.unt.edu (Minnis, Robert)
  10702. Date: Fri, 11 Mar 1994 20:15:23 GMT
  10703. Organization: College of Business Administration, UNT
  10704.  
  10705. In article <CMInE0.5nM@ra.nrl.navy.mil> temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple) writes:
  10706. >From: temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple)
  10707. >Subject: Resources on PowerPC
  10708. >Date: Fri, 11 Mar 1994 19:56:23 GMT
  10709.  
  10710. >There is an issue I have a little trouble with: it is my understanding
  10711. >that Native applications on the Power Macintosh will not use resources
  10712. >(or the resource fork.). What does this mean for programmers that are
  10713. >used to ResEdit for creating/editing resources, whose code points to
  10714. >reusable resources, etc? Will this feature of Mac programming simply
  10715. >cease to exist when writing Native RISC applications or is there an
  10716. >alternative approach that will treat part of the DATA fork on PPC Macs
  10717. >as editable, callable, reusable resources that a new version of ResEdit
  10718. >(DataEdit??) will able to work with?
  10719.  
  10720. >Ideas?
  10721.  
  10722. >From what I understand, resources are not going to vanish.  PPC code will be 
  10723. stored in the data fork (68K code will still be stored in CODE resources).
  10724.  
  10725. Robert Minnis
  10726.  
  10727. +++++++++++++++++++++++++++
  10728.  
  10729. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  10730. Date: Fri, 11 Mar 94 15:39:49 PST
  10731. Organization: Peirce Software, Inc.
  10732.  
  10733.  
  10734. In article <CMInE0.5nM@ra.nrl.navy.mil> (comp.sys.mac.programmer), temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple) writes:
  10735. > There is an issue I have a little trouble with: it is my understanding
  10736. > that Native applications on the Power Macintosh will not use resources
  10737. > (or the resource fork.). What does this mean for programmers that are
  10738. > used to ResEdit for creating/editing resources, whose code points to
  10739. > reusable resources, etc? Will this feature of Mac programming simply
  10740. > cease to exist when writing Native RISC applications or is there an
  10741. > alternative approach that will treat part of the DATA fork on PPC Macs
  10742. > as editable, callable, reusable resources that a new version of ResEdit
  10743. > (DataEdit??) will able to work with?
  10744.  
  10745. Resourse do *not* go away on the Power Mac.  PowerPC executable code
  10746. is not found in CODE resources (though it can be found in a few special
  10747. code resources) rather in the data fork.  Still, all other "normal"
  10748. Mac resources are still around and used.  In fact, CODE resource can
  10749. still contain 68K code - this is how you implement fat binaries.
  10750.  
  10751. So relax, ResEdit isn't going away.
  10752.  
  10753.  
  10754. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  10755. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  10756. --                       -- San Jose, California USA 95117
  10757. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  10758. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  10759.  
  10760. +++++++++++++++++++++++++++
  10761.  
  10762. >From richardb@cocytus.demon.co.uk (Richard Buckle)
  10763. Date: Sat, 12 Mar 1994 12:57:25 GMT
  10764. Organization: None
  10765.  
  10766.  
  10767. In article <CNjbKKKX.qcga43@outpost.SF-Bay.org> peirce@outpost.SF-Bay.org
  10768. (Michael Peirce) writes:
  10769. >
  10770. >...
  10771. >Resourse do *not* go away on the Power Mac.  PowerPC executable code
  10772. >is not found in CODE resources (though it can be found in a few special
  10773. >code resources) rather in the data fork.  Still, all other "normal"
  10774. >Mac resources are still around and used.  In fact, CODE resource can
  10775. >still contain 68K code - this is how you implement fat binaries.
  10776. >...
  10777.  
  10778. Arrgggh! How could Apple do this to me? I need my data forks for DATA.
  10779.  
  10780. A major part of my job is writing computationally *very* intensive XCMDs (for
  10781. HyperCard) and CODE resources (for Excel). These are of course stored in the
  10782. resource forks of stacks and spreadsheets and we need to turn them into fat
  10783. binaries. And HyperCard and Excel expect to call CODE and XCMD resources, not
  10784. any other type.
  10785.  
  10786. Will it be possible to have 68K stub resources call 'special' PowerPC
  10787. executable resources?
  10788.  
  10789. If not, I guess I shall have to store the PowerPC code in the data fork of
  10790. another file. As new releases are very frequent this would be an installation
  10791. nightmare. Would the new Shared Library Manager help at all?
  10792.  
  10793. BTW, how is the global A4 addressing issue handled in PowerPC standalone code?
  10794.  
  10795. Replies by mail please -- I shan't have time to read much news next week. I
  10796. shall summarise in c.s.m.p when the shouting is over.
  10797.  
  10798. Apologies if these are RTFM-type questions -- we have not yet taken delivery of
  10799. CodeWarrior so I am rather in the dark.
  10800.  
  10801. - -
  10802. Richard Buckle
  10803. richardb@cocytus.demon.co.uk
  10804. richardb@cix.compulink.co.uk
  10805.  
  10806. +++++++++++++++++++++++++++
  10807.  
  10808. >From wdh@netcom.com (Bill Hofmann)
  10809. Date: Sat, 12 Mar 1994 20:00:40 GMT
  10810. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  10811.  
  10812. richardb@cocytus.demon.co.uk (Richard Buckle) writes:
  10813. >A major part of my job is writing computationally *very* intensive XCMDs (for
  10814. >HyperCard) and CODE resources (for Excel). These are of course stored in the
  10815. >resource forks of stacks and spreadsheets and we need to turn them into fat
  10816. >binaries. And HyperCard and Excel expect to call CODE and XCMD resources, not
  10817. >any other type.
  10818. This seems to be enough of a FAQ that I've responded here as well as directly.
  10819. Michael misspoke himself slightly: BY DEFAULT, PowerPC code for APPLICATIONS
  10820. lives in the data fork of the file.  What this means is:
  10821.     * PPC application code can be in the data fork
  10822.     * PPC application code can be in one huge resource
  10823. You just have to set up the (mandatory) 'cfrg' resource properly.
  10824. Also:
  10825.     * standalone code resource can be all 680x0
  10826.     * standalone code resources can be all PowerPC
  10827.     * standalone code resources can be "fat", containing both
  10828. If standalone code will only be called from 680x0 code,
  10829.     * it can be plain vanilla 680x0 code, like today
  10830.     * it can be PPC code with a "RoutineDescriptor" at the front
  10831.     * it can be "fat" with a "RoutineDescriptor" at the front
  10832. 680x0 code doesn't need to know about the PowerPC AT ALL.
  10833.  
  10834. If standalone code will only be called from PowerPC code,
  10835.     * it can be naked PPC code
  10836.     * it can be PPC code with a RoutineDescriptor
  10837.     * it can be 680x0 code with a RoutineDescriptor
  10838.     * it can be "fat" with a RoutineDescriptor
  10839.     * it can be naked 680x0 code
  10840. In all but the FIRST (native PPC), it must be called using a special routine.
  10841. So if you write PPC-aware code, you need to read the MixedMode manager 
  10842. chapter of the Mac on RISC SDK.
  10843.  
  10844. If standalone code may be called from either 680x0 or PPC:
  10845.     * it can be naked 680x0 code
  10846.     * it can be PPC code with a RoutineDescriptor
  10847.     * it can be 680x0 code with a Routine Descriptor
  10848.     * it can be "fat" with a RoutineDescriptor
  10849. Since not all of the ToolBox and OS are native, ANY standard code resource
  10850. that contains PPC code MUST have a routine descriptor.  That goes for things
  10851. like XCMDs as well.
  10852.  
  10853.  
  10854. I think that about covers it.  Whoever maintains the FAQ might want to 
  10855. put this in there.
  10856.  
  10857. Oh yes, Apple Developer University is offering a course called "PowerPC
  10858. Boot Camp", which covers this and lots more.  It's a four day course,
  10859. with plenty of hands-on, including code resource kinda stuff.  I'm one
  10860. of the Drill Sargeants, oops, instructors, so, I have an ulterior motive.
  10861. -- 
  10862. -Bill Hofmann                    wdh@netcom.COM
  10863.  Fresh Software and Instructional Design    +1 510 524 0852
  10864.  
  10865. +++++++++++++++++++++++++++
  10866.  
  10867. >From Mark_Day@powertalk.apple.com (Mark Day)
  10868. Date: Sat, 12 Mar 1994 00:11:42 GMT
  10869. Organization: Apple Computer, Inc.
  10870.  
  10871. In article <CMInE0.5nM@ra.nrl.navy.mil>, temple@itd.nrl.navy.mil (Dr. Jon
  10872. Gerard Temple) wrote:
  10873.  
  10874. > There is an issue I have a little trouble with: it is my understanding
  10875. > that Native applications on the Power Macintosh will not use resources
  10876. > (or the resource fork.). What does this mean for programmers that are
  10877. > used to ResEdit for creating/editing resources, whose code points to
  10878. > reusable resources, etc? Will this feature of Mac programming simply
  10879. > cease to exist when writing Native RISC applications or is there an
  10880. > alternative approach that will treat part of the DATA fork on PPC Macs
  10881. > as editable, callable, reusable resources that a new version of ResEdit
  10882. > (DataEdit??) will able to work with?
  10883. > Ideas?
  10884.  
  10885. The code for native applications is normally found in the data fork,
  10886. not a bunch of CODE resources (for non-native code).  You can (and
  10887. should) still use resources.  In fact, you can have a "fat" application
  10888. with both CODE resources and native code in the data fork, that share
  10889. other non-code resources (like strings, icons, etc.).  Such "fat"
  10890. applications will execute the native code on Power Macintosh or the
  10891. old 68K CODE resources on non-Power Macintoshes.
  10892. -- 
  10893. Mark Day, Apple Computer, Inc.
  10894. mday@apple.com
  10895.  
  10896. ---------------------------
  10897.  
  10898. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  10899. Subject: Safer Segments ?
  10900. Date: 15 Mar 94 16:49:06
  10901. Organization: Integrated Systems Laboratory, ETH, Zurich
  10902.  
  10903. My program usually has multiple resource files open, some of which contain CODE
  10904. resources (they are similar to AppleScript droplets). Unfortunately, if
  10905. _LoadSeg is called while one of the other CODE containing resource forks is
  10906. in front of the resource chain, a nasty crash results. So far, I have been able
  10907. to work around this problem by calling UseResFile() in all the right places,
  10908. but I'd prefer to know a simpler solution, if one exists.
  10909.  
  10910. Any ideas?
  10911.  
  10912. Matthias
  10913.  
  10914. - ---
  10915. Matthias Neeracher                                      neeri@iis.ee.ethz.ch
  10916.    "I really don't want the SNMP agent controlling my toilet to tell
  10917.     someone when/where I'm using it." -- Sean Graham
  10918.  
  10919. +++++++++++++++++++++++++++
  10920.  
  10921. >From wysocki@netcom.com (Chris Wysocki)
  10922. Date: Wed, 16 Mar 1994 10:02:35 GMT
  10923. Organization: Global Village Communication, Mountain View, CA
  10924.  
  10925. In article <NEERI.94Mar15164906@yggdrasil.ethz.ch> neeri@iis.ee.ethz.ch (Matthias Neeracher) writes:
  10926.  
  10927. >My program usually has multiple resource files open, some of which contain CODE
  10928. >resources (they are similar to AppleScript droplets). Unfortunately, if
  10929. >_LoadSeg is called while one of the other CODE containing resource forks is
  10930. >in front of the resource chain, a nasty crash results. So far, I have been able
  10931. >to work around this problem by calling UseResFile() in all the right places,
  10932. >but I'd prefer to know a simpler solution, if one exists.
  10933.  
  10934. It's hardly simple, but the most robust thing to do is to patch
  10935. _LoadSeg and have your patch set the current resource file, call the
  10936. "real" _LoadSeg and restore the previous resource file on the way out.
  10937. Patching _LoadSeg also allows you to preflight the loading of the code
  10938. resources so that you can avoid crashing in the event that the Segment
  10939. Loader can't load the segment.  I've use this technique in a number of
  10940. applications and it works quite well; if you have MacApp 3.x, take a
  10941. look at UMemory.cp and UMemory.a to see how it can be done.
  10942.  
  10943. Chris.
  10944.  
  10945. +++++++++++++++++++++++++++
  10946.  
  10947. >From Greg_Marriott@genmagic.com (Greg Marriott)
  10948. Date: Thu, 17 Mar 1994 02:26:31 -0800
  10949. Organization: General Magic, Inc.
  10950.  
  10951. neeri@iis.ee.ethz.ch (Matthias Neeracher) wrote:
  10952.  
  10953. > [...] if _LoadSeg is called while one of the other CODE
  10954. > containing resource forks is in front of the resource chain, a nasty
  10955. > crash results. So far, I have been able to work around this problem
  10956. > by calling UseResFile() in all the right places, [...]
  10957. > Any ideas?
  10958.  
  10959. I don't know if you'll think this is simpler or not... You might try
  10960. patching _LoadSeg to call UseResFile() before jumping to the original code.
  10961.  
  10962. -- 
  10963. Greg Marriott
  10964. Just Some Guy
  10965. General Magic, Inc.
  10966.  
  10967. Disclaimer: My opinions are not necessarily the same as General Magic's.
  10968.             (can a company even HAVE an opinion?)
  10969.  
  10970. +++++++++++++++++++++++++++
  10971.  
  10972. >From ari@world.std.com (Ari I Halberstadt)
  10973. Date: Thu, 17 Mar 1994 21:08:39 GMT
  10974. Organization: The World Public Access UNIX, Brookline, MA
  10975.  
  10976. In article <NEERI.94Mar15164906@yggdrasil.ethz.ch>,
  10977. Matthias Neeracher <neeri@iis.ee.ethz.ch> wrote:
  10978. >My program usually has multiple resource files open, some of which contain CODE
  10979. >resources (they are similar to AppleScript droplets). Unfortunately, if
  10980. >_LoadSeg is called while one of the other CODE containing resource forks is
  10981. >in front of the resource chain, a nasty crash results. So far, I have been able
  10982. >to work around this problem by calling UseResFile() in all the right places,
  10983. >but I'd prefer to know a simpler solution, if one exists.
  10984.  
  10985. You can patch the _LoadSeg trap. Here's the code I use to patch
  10986. LoadSeg. It checks that there's enough memory available before loading
  10987. the segment. If you add a call to UseResFile just before and after the
  10988. GetResource call it should do what you need. The PatchType structure
  10989. contains info about the patch that you'd set when installing the
  10990. patch, though you could just use some global variable to hold the
  10991. address of the routine returned by NGetTrapAddress.
  10992.  
  10993. /* data needed by a patch */
  10994. typedef struct PatchType {
  10995.    struct PatchType *next;      /* next patch */
  10996.    pascal void (*addr)(...);   /* address of patch routine */
  10997.    pascal void   (*trap)(...);   /* saved trap address */
  10998.    TrapType      type;            /* type of trap */
  10999.    short         num;            /* number of trap */
  11000.    Boolean      installed;      /* true if patch was installed */
  11001. } PatchType, *PatchPtr, **PatchHandle;
  11002.  
  11003. /* The PATCH_ENTER macro should be the first executable statement in
  11004.    your patch routine. PATCH_ENTER saves all of the registers and sets
  11005.    up register a5. PATCH_ENTER also ensures that the routine has a stack
  11006.    frame so that the PATCH_RETURN macro can be used. */
  11007. #define PATCH_ENTER() \
  11008.    {   long _patch_force_stack_frame; {      /* force stack frame of at least 4 bytes */ \
  11009.       asm { movem.l a0-a5/d0-d7, -(sp) }   /* save registers */ \
  11010.       asm { move.l #0x0904, a5 }            /* setup register a5 */ \
  11011.       asm { move.l (a5), a5 }
  11012.  
  11013. // this PATCH_RETURN macro magically restores registers d0-d7/d0-a7 to the
  11014. // same values they had when it was entered, which makes it a pretty
  11015. // safe way to patch traps (note: well, i've only been using this code
  11016. // for about a week, but i stepped through it and it should work).
  11017.  
  11018. /* The PATCH_RETURN macro jumps to the address of the originally patched
  11019.    routine. You should call PATCH_RETURN at the end of your patch. The
  11020.    'patch' parameter should be a pointer returned from PatchBegin. The
  11021.    compiler must generate a stack frame (using register a6) for the patch
  11022.    routine. This should be ensured by the PATCH_ENTER macro. */
  11023. #define PATCH_RETURN(patch) \
  11024.    } } \
  11025.    { \
  11026.       asm { move.l a6, a1 }               /* get current value of a6 */ \
  11027.       asm { move.l (a6), -(a6) }            /* shift location of saved a6 */ \
  11028.       asm { move.l patch, a0 }            /* get pointer to patch record */ \
  11029.       asm { move.l PatchType.trap(a0), (a1) } /* put patched routine's address on stack */ \
  11030.       asm { movem.l (sp)+, a0-a5/d0-d7 }   /* restore registers */ \
  11031.       asm { unlk a6 }                     /* pop stack frame */ \
  11032.       asm { rts }                           /* return to patched routine */ \
  11033.    }
  11034.  
  11035. static PatchType *gPatchLoadSeg;   /* data about patch */
  11036.  
  11037. /* get a code resource */
  11038. static Handle GetCodeResource(ResID id)
  11039. {
  11040.    Handle code;
  11041.    
  11042.    require(LMGetResLoad());
  11043.    SetResLoad(false);
  11044.    code = GetResource('CODE', id);
  11045.    SetResLoad(true);
  11046.    FailNILRes(code);
  11047.    /* We use MemAvailableNoCushion since MemAvailable could unload
  11048.       segments, and if segments are unloaded from within this patch
  11049.       the program crashes. */
  11050.    if (! *code && ! MemAvailableNoCushion(SizeResource(code)))
  11051.       FailOSErr(memFullErr);
  11052.    SetResAttrs(code, GetResAttrs(code) & ~resLocked);
  11053.    FailResError();
  11054.    LoadResource(code);
  11055.    FailResError();
  11056.    return(code);
  11057. }
  11058.  
  11059. /* For its own reasons, perhaps related to using FAR code, THINK C seems
  11060.    to patch the _LoadSeg trap. THINK C also makes code resources locked.
  11061.    Unfortunately, this prevents _LoadSeg from calling MoveHHi on segments,
  11062.    even if the low-memory global SegHiEnable is non-zero. Having code
  11063.    segments low in memory leads to severe heap fragmentation when pointers
  11064.    are allocated above the code segments. This patch will load the resource,
  11065.    move it to the top of the heap, and lock it there. This patch will also
  11066.    trigger an exception if the resource couldn't be loaded or if there isn't
  11067.    enough memory to load the resource. */
  11068. static pascal void PatchLoadSeg(ResID segnum)
  11069. {
  11070.    Handle code;
  11071.    
  11072.    PATCH_ENTER();
  11073.    code = GetCodeResource(segnum);
  11074.    if (code && LMGetSegHiEnable()) {
  11075.       MoveHHi(code);
  11076.       HLock(code);
  11077.    }
  11078.    PATCH_RETURN(gPatchLoadSeg);
  11079. }
  11080.  
  11081. // this has nothing to do with the above patch, but could be useful
  11082. // to someone who wants to load a segment
  11083.  
  11084. pascal void LoadSegTrap(ResID seg) = _LoadSeg; 
  11085.  
  11086. /* load the segment */
  11087. static void LoadSeg(ResID seg)
  11088. {
  11089.    asm {
  11090.             move.w seg, -(sp)
  11091.             bra.s @1    /* call LoadSeg */
  11092.             bra.s @2    /* LoadSeg returns here */
  11093.             nop          /* fill up two bytes */
  11094.       @1:   LoadSegTrap
  11095.       @2:
  11096.    }
  11097. }
  11098. -- 
  11099. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  11100. "These beetles were long considered to be very rare because very few
  11101. entomologists look for beetles in the mountains, in winter, at night,
  11102. during snow storms." -- Purves W. K., et al, "Life: The Science of
  11103.  
  11104. ---------------------------
  11105.  
  11106. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  11107. Subject: Speeding up animation; questions
  11108. Date: Sun, 27 Feb 1994 23:49:11 GMT
  11109. Organization: The Great Beyond
  11110.  
  11111. Ramble alert!  (This one's kinda long..)
  11112.  
  11113. Hi gang!
  11114.  
  11115.    I found a few minutes this weekend to revisit my much-procrastinated
  11116. tour into the development of Mac arcade games..  (Well, I haven't really
  11117. procrastinated, I just haven't had the time.  :(
  11118.  
  11119.    I've been developing a direct-screen animation toolkit which I'll
  11120. (eventually) be using to write games.  I'm now working on the "animation
  11121. engine" -- the heart of the game where all of the animation will be
  11122. performed.
  11123.  
  11124.    What I'll do is describe the method(s) I'm thinking about using.  Any
  11125. comments on my methods would be greatly appreciated; don't hesitate to
  11126. tell me that I'm going about it all the wrong way.
  11127.  
  11128.    The type of game I'll be writing will probably be similar to Lemmings,
  11129. in that I need to have support for lots of (fairly small) sprites.  Having
  11130. 30 separate sprites on screen and moving is not too much to ask.  (It may
  11131. be too much to program, but...)  But they'll generally be 32x32 pixels or
  11132. smaller, with room for a few larger ones.  I'll write this game to fill
  11133. the 12" monitor -- 512x384 pixels.  It will only support color, probably
  11134. require System 7, etc.  And it uses "direct-screen" drawing; filling the
  11135. video RAM with bytes for instant gratification.
  11136.  
  11137.    First question: will direct-screen animation work on the PowerPC, if
  11138. the loosely-defined "correct" way of doing it is followed?  From what I
  11139. have heard and seen of the PowerPC, it doesn't seem like there's any
  11140. inhibiting factors against using direct-screen graphics.  But I haven't
  11141. gotten my hands on a PPC compiler yet to try it out.
  11142.  
  11143.    Ok.  So, here's how I'll do my animation: I'll have two buffers (at
  11144. about 384k each -- this game will probably require at least 2 megs) the
  11145. size of the game area.  One of these buffers contains the background.
  11146. The other buffer is a "work" buffer.  First I copy the entire background
  11147. to the work buffer.  Then I mask or draw all of my sprites on top of the
  11148. background in the work buffer.  Then I copy the work buffer to the screen.
  11149. The process continues for each frame of animation.  I'll sync the drawing
  11150. with the electron beam, if necessary.
  11151.  
  11152.    From previous discussions here and elsewhere, this seems to be an
  11153. accepted method that will result in flicker-free animation.  It's memory-
  11154. intensive, but as I have described it, relatively easy to implement.
  11155.  
  11156.    But (at least) two things bother me: there's two copies of 512x384 bytes
  11157. occurring for each frame of animation: first the copy of the background
  11158. into the work buffer, then the copy of the work buffer to the screen.  Not
  11159. to mention all the copies of the sprites -- possibly up to 30.
  11160.  
  11161.    I know there are probably ways to prevent copying the entire screen,
  11162. and I could use some suggestions.  I could keep track of a "dirty rectangle"
  11163. that needs updating, but for my game I'll have sprites all over the screen
  11164. so it seems like I'll need to copy the whole screen anyway.  Keeping a
  11165. list of rectangles needing to be copied is another possibility, but this
  11166. will result in a lot of overhead and required computations, and numerous
  11167. little copies that would probably make it slower.
  11168.  
  11169.    I did some (rough) experimentation.  I took two sprites, each 512x384,
  11170. and blasted them to the screen in alternating order for 30 seconds,
  11171. incrementing a counter with each blast.  I did this on a Macintosh IIfx.
  11172. Here are the results:
  11173.  
  11174.   No optimizations:        356 frames / 30 seconds or 11.87 frames/s
  11175.   Compiled for 68020 and up,
  11176.     with all Symantec C++ opts: 554 frames / 30 seconds or 18.47 frames/s
  11177.  
  11178.    Comments: I used the Symantec C++ compiler.  And keep in mind I'll
  11179. have at least two full copies going on for each frame, plus all the work
  11180. involved in drawing the numerous sprites, overhead from the rest of the
  11181. game's I/O and logic, etc.  I don't think a bad prediction would be that
  11182. with those results, I might end up with around 6 frames per second.  Isn't
  11183. that pretty bad?  For arcade games, how many "complete" screen updates / s
  11184. are there usually?  (I've also got to remind myself that I'm developing
  11185. this on a IIfx -- which (for now) is still speedier than the average Mac.)
  11186.  
  11187.    Here's the code I use for blasting the 512x384 sprite to the screen:
  11188.  
  11189. void
  11190. Sprite::Plot(long x, long y)
  11191. {
  11192.   long        *longPtr, *longPtr2;
  11193.   register long    xx;
  11194.   register long    yy;
  11195.   long        sum1, sum2;
  11196.   
  11197.   if (data_allocated == 1)
  11198.   {
  11199.     HLock(theData);
  11200.     
  11201.     longPtr2 = (long *)(*theData);
  11202.     sum1 = y + height;
  11203.     sum2 = x + width;
  11204.     for (yy=y; yy<sum1; yy++)
  11205.     {
  11206.       longPtr = (long *)(x + theScreen->line_ptr[yy]);
  11207.       for (xx=x; xx<sum2; xx+=4)
  11208.         *longPtr++ = *longPtr2++;
  11209.     }
  11210.     
  11211.     HUnlock(theData);
  11212.   }
  11213.   
  11214. }
  11215.  
  11216.    line_ptr is an array of the addresses that start each line of the video
  11217. RAM.  Also, the way this is written, it requires the width and the height
  11218. of the sprite to be divisible by 4.  theData is just a chunk of memory
  11219. containing a stream of bytes representing the colors of the 8-bit sprites.
  11220.  
  11221.    Can anyone think of ways to optimize this?  I could post the dissassembly
  11222. but this message is long enough.  (I'm still a stranger to assembly
  11223. language so I have trouble noting obvious inefficiencies in the dissasembly.)
  11224.  
  11225.    (And if you guys don't kill me first, I'd love to post my version of
  11226. a masking copy routine so you all can tell me how horribly inefficient
  11227. THAT is..  Although it seems pretty quick.)
  11228.  
  11229.    (How would CopyBits compare?)
  11230.  
  11231.    Well, I guess that's about it.  For the type of game I've described,
  11232. am I approaching this in the correct manner?  If not, what other techniques
  11233. should I try?  If so, how can I approach it more efficiently?  I'm
  11234. looking for speed.  I'm not sure if I've found it yet.
  11235.  
  11236.    Again, ANY comments would be appreciated.  I've only gotten this far
  11237. by generous help from Ingemar Ragnemalm, Matt Hall, Tom Dowdy, Juri
  11238. Munkki, Rick Holzgrafe, Jon Witte, Julian Harris, and others..  (Sorry
  11239. if I killed anyone's spelling; you probably don't even remember helping
  11240. me, as I first posed these types of questions back in November of '92.
  11241. I archived your messages and have referred to them often.)
  11242.  
  11243. Later!
  11244.  
  11245. - M. Scott Smith     [mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu]
  11246.  
  11247.   Macintosh developer, student, ski bum.  Eater of Kellogg's Frosted Flakes.
  11248.  
  11249.   "Last chance for fuel on information highway."
  11250.  
  11251.  
  11252. +++++++++++++++++++++++++++
  11253.  
  11254. >From john_werner@taligent.com (John Werner)
  11255. Date: Mon, 28 Feb 1994 03:18:49 GMT
  11256. Organization: Taligent, Inc.
  11257.  
  11258. In article <1994Feb27.234911.14595@afterlife.ncsc.mil>,
  11259. mssmith@afterlife.ncsc.mil (M. Scott Smith) wrote:
  11260.  
  11261. >    But (at least) two things bother me: there's two copies of 512x384 bytes
  11262. > occurring for each frame of animation: first the copy of the background
  11263. > into the work buffer, then the copy of the work buffer to the screen.  Not
  11264. > to mention all the copies of the sprites -- possibly up to 30.
  11265.  
  11266. You're right.  This will be too slow, as your experiment below shows.
  11267.  
  11268. > Keeping a
  11269. > list of rectangles needing to be copied is another possibility, but this
  11270. > will result in a lot of overhead and required computations,
  11271.  
  11272. This is probably the way to do it.  If you try hard enough you can optimize
  11273. the list of rectangles by merging ones that overlap or are adjacent.  To
  11274. make things more complicated, you need to do this all twice: once for
  11275. copying from your background bitmap to the work buffer, then for the copy
  11276. from the work buffer to the screen.  When copying from the background, you
  11277. only need to copy the areas corresponding to the sprites' old locations (to
  11278. erase them).  When copying to the screen, you need the union of the old and
  11279. new sprite locations, to erase the old sprites and draw the new ones. 
  11280.  
  11281. Another strategy would be to divide the screen up into an even grid of
  11282. rectangles.  If a rectangle contains any sprites then it gets copied;
  11283. otherwise it doesn't.  This would work best if you know your sprites are
  11284. usually going to be concentrated in certain areas rather than randomly
  11285. scattered around the screen.
  11286.  
  11287. > and numerous little copies that would probably make it slower.
  11288.  
  11289. You should test this before you assume it's true.  If the bit depths and
  11290. color tables all match, most of the time is going to be spent writing bits
  11291. to the screen.
  11292.  
  11293. Other tips:
  11294.  
  11295. Make sure all of your bitmaps are longword-aligned.
  11296.  
  11297. Make sure all the color tables and bit depths match.  CopyBits can slow
  11298. down a lot when they don't.  With a custom blitter life will be a lot
  11299. simpler if you don't have to worry about such things.
  11300.  
  11301. Expand the left and right edges of areas to be copied so that they end on
  11302. byte (or word, or longword) boundaries, so CopyBits or your custom blitter
  11303. has a much simpler job to do.
  11304.  
  11305. > I don't think a bad prediction would be that
  11306. > with those results, I might end up with around 6 frames per second.  Isn't
  11307. > that pretty bad?
  11308.  
  11309. Yes.  You need 20 fps or so to look at all decent.  30 would be even
  11310. better.
  11311.  
  11312. -- 
  11313. John Werner                          john_werner@taligent.com
  11314. Taligent, Inc.
  11315.  
  11316. +++++++++++++++++++++++++++
  11317.  
  11318. >From Turly.OConnor@isltd.insignia.com (Turly OConnor)
  11319. Date: 28 Feb 1994 10:39:45 -0600
  11320. Organization: UTexas Mail-to-News Gateway
  11321.  
  11322. M. Scott Smith had a few questions regarding speeding up his sprite drawer.
  11323. Here's one:
  11324.  
  11325.   - Don't bother with locking and unlocking the handle!
  11326.     Since you don't call anything which moves memory, there's no point.
  11327.     The trap dispatcher overhead is likely to be bigger than your entire
  11328.     sprite copying loop!
  11329.  
  11330.   - Re-organise your code so you use
  11331.       do {
  11332.          *longPtr++ = *spritePtr++;
  11333.       } while (--xx);
  11334.     instead of the for(;;) loop you've currently got.
  11335.  
  11336.   - If you know the sprites are 32 pixels wide, unroll your x-loop so
  11337.     that you write all 32 pixels at once; in fact, get rid of your x-loop
  11338.     altogether.
  11339.  
  11340. Oops, sorry, more than one but what the heck!
  11341.  
  11342. Have fun!
  11343.  
  11344. --turly
  11345.  
  11346. +++++++++++++++++++++++++++
  11347.  
  11348. >From al@crucible.powertools.com (Al Evans)
  11349. Date: 28 Feb 94 16:51:00 GMT
  11350. Organization: PowerTools, Austin, Texas
  11351.  
  11352. In article <1994Feb27.234911.14595@afterlife.ncsc.mil> mssmith@afterlife.ncsc.mil (M. Scott Smith) writes:
  11353.  
  11354. [Sprite animation, wants to support up to 30 32X32 sprites]
  11355.  
  11356. >   First question: will direct-screen animation work on the PowerPC, if
  11357. >the loosely-defined "correct" way of doing it is followed?  From what I
  11358. >have heard and seen of the PowerPC, it doesn't seem like there's any
  11359. >inhibiting factors against using direct-screen graphics.  But I haven't
  11360. >gotten my hands on a PPC compiler yet to try it out.
  11361.  
  11362. Consider the possibility that you may be working on the wrong thing.
  11363. First, it's difficult to beat CopyBits by much when you're using
  11364. srcCopy mode and everything is ligned up right (assuming 8-bit color
  11365. with value of ctSeed equal in offscreen GWorld and onscreen device).
  11366. Second, remember that even eliminating the offscreen-to-onscreen copy
  11367. COMPLETELY will only make you about 30% faster (which may be what you
  11368. have to do to get the performance you want). Third, remember that
  11369. CopyBits will always be supported and will work on all Macs.
  11370.  
  11371. [Description of animation loop: offscreen-to-offscreen copy of
  11372. entire background, offscreen-to-offscreen to sprites, offscreen-to-
  11373. onscreen of composite]
  11374.  
  11375. >   I know there are probably ways to prevent copying the entire screen,
  11376. >and I could use some suggestions.  I could keep track of a "dirty rectangle"
  11377. >that needs updating, but for my game I'll have sprites all over the screen
  11378. >so it seems like I'll need to copy the whole screen anyway.  Keeping a
  11379. >list of rectangles needing to be copied is another possibility, but this
  11380. >will result in a lot of overhead and required computations, and numerous
  11381. >little copies that would probably make it slower.
  11382.  
  11383. My tests indicate that the overhead of maintaining a sorted list of
  11384. update Rects is small compared to the time saved in copying. Look at
  11385. it this way: if you only save 4 pixels at each side of the window,
  11386. that's 4 * 384 * 2 bytes that don't have to be moved, or enough bytes
  11387. for 3 32X32X8 sprites.
  11388.  
  11389. [timing tests]
  11390.  
  11391. >I might end up with around 6 frames per second.  Isn't
  11392. >that pretty bad?  For arcade games, how many "complete" screen updates / s
  11393. >are there usually?  (I've also got to remind myself that I'm developing
  11394. >this on a IIfx -- which (for now) is still speedier than the average Mac.)
  11395.  
  11396. I've done some pretty extensive speed testing lately in finishing up
  11397. my Graphic Elements system (watch this space for announcements Real Soon
  11398. Now). I use a somewhat similar double buffering technique. I find that
  11399. I can get 8 frames/second on a Mac IIsi with 30 32X32 sprites scattered
  11400. over the screen and moving randomly. This drops to 7 fps with a "load",
  11401. i.e. collision processing. On a Quadra 800, the numbers are 33 and
  11402. 29, respectively. I do not believe that these numbers can be substantially
  11403. improved without going to a different animation scheme (but I'd love
  11404. to be proved wrong:-).
  11405.  
  11406. [...]
  11407.  
  11408. >   Well, I guess that's about it.  For the type of game I've described,
  11409. >am I approaching this in the correct manner?  If not, what other techniques
  11410. >should I try?  If so, how can I approach it more efficiently?  I'm
  11411. >looking for speed.  I'm not sure if I've found it yet.
  11412.  
  11413. "Correct" is a big word, but you're approaching it in the only highly
  11414. general manner (i.e. offscreen construction, off-to-onscreen copy).
  11415. If I were you, I would look at the following possibilities: 1) Use
  11416. smaller sprites or fewer of them; 2) Keep a list of dirty Rects and
  11417. copy only what you have to; 3) Try to "offset" your frame generation
  11418. so that, for example, only 1/3 of the sprites need updating on a
  11419. given frame (of course this only works in conjunction with 2).
  11420.  
  11421.                     --Al Evans--
  11422. -- 
  11423.  
  11424. Al Evans                         Tu causes, tu causes
  11425. al@crucible.powertools.com               C'est tout ce que tu sais faire
  11426. cs.utexas.edu!crucible!al                     -- LaVerdure
  11427.  
  11428. +++++++++++++++++++++++++++
  11429.  
  11430. >From mxmora@unix.sri.com (Matt Mora)
  11431. Date: 28 Feb 1994 09:33:03 -0800
  11432. Organization: SRI International, Menlo Park, CA
  11433.  
  11434. In article <1994Feb27.234911.14595@afterlife.ncsc.mil> mssmith@afterlife.ncsc.mil (M. Scott Smith) writes:
  11435.  
  11436.  
  11437. >   I know there are probably ways to prevent copying the entire screen,
  11438. >and I could use some suggestions.  I could keep track of a "dirty rectangle"
  11439. >that needs updating, but for my game I'll have sprites all over the screen
  11440. >so it seems like I'll need to copy the whole screen anyway.  Keeping a
  11441. >list of rectangles needing to be copied is another possibility, but this
  11442. >will result in a lot of overhead and required computations, and numerous
  11443. >little copies that would probably make it slower.
  11444.  
  11445. You get lots of suggestions about optimizations but one thing you should
  11446. remember, try any move as little bytes as possible. You will never
  11447. be able to an entire screen in one tick on apples current hardware. Maybe
  11448. this will be possible in PowerPC and we will finally be able to play games
  11449. with a scrolling background. :-)
  11450.  
  11451. If you have many sprites union their rects and copy that data. Though
  11452. you are copying more data than you need to you should win by being able
  11453. to move longwords at a time. 
  11454.  
  11455.  
  11456. Xavier
  11457.  
  11458.  
  11459.  
  11460. -- 
  11461. ___________________________________________________________
  11462. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  11463. SRI International                       mxmora@unix.sri.com
  11464. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  11465.  
  11466. +++++++++++++++++++++++++++
  11467.  
  11468. >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault)
  11469. Date: Mon, 28 Feb 1994 13:26:21 -0500
  11470. Organization: Motorola Codex
  11471.  
  11472. In article <1994Feb27.234911.14595@afterlife.ncsc.mil>,
  11473. mssmith@afterlife.ncsc.mil (M. Scott Smith) wrote:
  11474.  
  11475. >    The type of game I'll be writing will probably be similar to Lemmings,
  11476. > in that I need to have support for lots of (fairly small) sprites.  Having
  11477. > 30 separate sprites on screen and moving is not too much to ask.  (It may
  11478. > be too much to program, but...)  But they'll generally be 32x32 pixels or
  11479. > smaller, with room for a few larger ones.  I'll write this game to fill
  11480. > the 12" monitor -- 512x384 pixels.  It will only support color, probably
  11481. > require System 7, etc.  And it uses "direct-screen" drawing; filling the
  11482. > video RAM with bytes for instant gratification.
  11483.  
  11484. >    Well, I guess that's about it.  For the type of game I've described,
  11485. > am I approaching this in the correct manner?  If not, what other techniques
  11486. > should I try?  If so, how can I approach it more efficiently?  I'm
  11487. > looking for speed.  I'm not sure if I've found it yet.
  11488.  
  11489.  
  11490. Some comments:
  11491.  - if you have a lot of sprites moving on screen then it may be better to
  11492. optimize the background copy operation between your saved background and
  11493. your work buffer (the one you do a CopyBits to the screen with).  You can
  11494. unroll a loop in assembler and refresh your work buffer real fast. Then you
  11495. can do all the real drawing in your work buffer. Given your type of game
  11496. you have to determine if the overhead of tracking and updating invalid
  11497. rects is worth the time. Generally the more smaller rects you need to
  11498. update, the easier it is to save time by just doing a real fast copy of the
  11499. buffer. I would calculate a dirty rect for all sprites drawn in the work
  11500. buffer though, so what I actually have to copy to the screen would remain
  11501. the minimal update rect. (Don't forget to adjust this update rect to the
  11502. proper multiple of 32 for both left and right edges!) Once calculated, you
  11503. use this rect to restore the background on the next pass!
  11504.  
  11505. - You really don't want to play with direct screen drawing for this style
  11506. of animation for a couple of reasons:  Directly writing to the video memory
  11507. can get you clobbered by some graphics accellerators. If you allow the user
  11508. to switch out to the Finder and s/he changes the depth of the monitor on
  11509. the fly, and you don't check it, you're in ds trouble.  Also, although you
  11510. can sync up to obtain a nice smooth animation with vertical blanking you
  11511. still can end up trying to beat the electron gun.  If, in drawing directly
  11512. to video memory, you end up drawing the last item in your sprite drawlist
  11513. near the top of the screen when the vertical blanking interval is over,
  11514. you'll end up with a tearing effect. There is overhead in trying to order
  11515. sprites, both for front-back and top-bottom drawing (to provide tear-free
  11516. animation). Also, given you may have a higher refresh rate on some
  11517. monitors, you'd be playing with an unknown. (Spend more of your development
  11518. time trying to avoid hardware related issues - you'll thank me later! ;-) )
  11519.  
  11520. - I'm assuming that you're going to look through your GDeviceList and set
  11521. up your VBL task in the correct slot to synch with the monitor or monitors.
  11522. Again, be aware of different refresh rates for monitors.
  11523.  
  11524. - Sometimes you don't need a high frame rate to achieve the appearence of a
  11525. very fast frame rate. For example if you attain 30fps moving your sprites 1
  11526. pixel position on the screen you can achieve the same "look" by moving your
  11527. sprites 2 pixel positions for only 15 fps. AND... if you're tearing at
  11528. 30fs, but tear-free at 15 fps...the user will prefer the smooth look vs the
  11529. choppy.     
  11530.  
  11531. - Do everything in your offscreen buffer then use CopyBits to move the
  11532. dirtyRect to screen...even if CopyBits has to make the transition to
  11533. different bit depths, chances are it will stay ahead of the electron gun
  11534. and you'll still get robust, smooth flicker-free animation and your game
  11535. will have a nice long life. (See Inside Mac III, p20. Although the values
  11536. are off, the ideas are still valid!)
  11537.  
  11538. - The only time direct screen drawing is really affordable (or necessary)
  11539. is when you're doing extremely minimal updates to an existing image using
  11540. polygons and the like or performing a non-rectangular copy (for example
  11541. doing a custom block copy that skews the image to some arbitrary angle.)
  11542. (Rule of thumb - if you have a lot of game event overhead time, like
  11543. network games or computing intelligence for chars, then simplify the
  11544. graphics to absolute minimum - most successful with poly or solid color
  11545. updates)  Sounds like your sprites do internal animation - if this is the
  11546. case you have to do complete draw of the new sprite each pass anyway.
  11547.  
  11548. Also it might be nicer to concentrate on supporting B&W versions if
  11549. possible...in terms of market there is still a lot of B&W Mac's out
  11550. there...including a lot of new PowerBooks.
  11551.  
  11552. BTW - in Sprite::Plot, you can increase the speed considerably by unrolling
  11553. the loop (for every iteration of the loop code overhead try to copy as many
  11554. longwords as you can!)
  11555.  
  11556.  
  11557. Good luck and put me on your beta test list!
  11558. Chris
  11559.  
  11560. -- 
  11561. #include <UsualLegalDisclaimers.h>
  11562. #define AnnoyThem  "This bug's for you!"
  11563.  
  11564. +++++++++++++++++++++++++++
  11565.  
  11566. >From u9119523@sys.uea.ac.uk (Graham Cox)
  11567. Date: Tue, 1 Mar 1994 18:22:04 GMT
  11568. Organization: School of Information Systems, UEA, Norwich
  11569.  
  11570. In article <1994Feb27.234911.14595@afterlife.ncsc.mil>,
  11571. mssmith@afterlife.ncsc.mil (M. Scott Smith) wrote:
  11572.  
  11573. > Ramble alert!  (This one's kinda long..)
  11574. > Hi gang!
  11575. >    I found a few minutes this weekend to revisit my much-procrastinated
  11576. > tour into the development of Mac arcade games..  (Well, I haven't really
  11577. > procrastinated, I just haven't had the time.  :(
  11578. >    I've been developing a direct-screen animation toolkit which I'll
  11579. > (eventually) be using to write games.  I'm now working on the "animation
  11580. > engine" -- the heart of the game where all of the animation will be
  11581. > performed.
  11582. [deleted]
  11583.  
  11584.  
  11585. > - M. Scott Smith     [mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu]
  11586. >   Macintosh developer, student, ski bum.  Eater of Kellogg's Frosted Flakes.
  11587. >   "Last chance for fuel on information highway."
  11588.  
  11589. If you're the type who likes to reinvent the wheel, (like we all are at
  11590. times!) then go ahead and don't let me stop you. 
  11591.  
  11592. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11593. identically to the way you describe, with a pair of offscreen work areas.
  11594. It generates sprites from PICT or cicn resources, and uses the time manager
  11595. to give sub-tick accuracy. It also has hooks for writing custom blitting
  11596. routines, and comes with one for 8-bit colour direct screen blitting, or
  11597. can use CopyBits. The example program turned in something like 100
  11598. frames/sec on a Centris 610 animating 5 or 6 50 x 50 pixel sprites. I got
  11599. 64 frames/sec on my IIsi! It also has full layer support and collision
  11600. detection. It is stable and easy to use- I rolled it into one of my C
  11601. applications in one evening and never had the slightest trouble compiling
  11602. it.
  11603.  
  11604.  
  11605. Now I have SpriteWorld, I am never going to write another sprite-animation
  11606. routine again!
  11607.  
  11608. I would also say that I have nothing whatsoever to do with its author, but
  11609. I am one very satisfied "customer" -and word-of-mouth advertising is the
  11610. best kind!
  11611.  
  11612. A technical point- SpriteWorld uses linked lists to store the data for each
  11613. sprite, not arrays. I wonder which method is faster? I reckon that the
  11614. performance is not bound by this anyway, but on the number of pixels
  11615. blitted per frame. SpriteWorld seems to go to a lot of trouble to minimise
  11616. the number of pixels blitted per frame, adding a little code overhead to
  11617. check this, but its high performance seems to suggest that this is a good
  11618. strategy.
  11619.  
  11620. - ------------------------------------------------------------------------
  11621. Love & BSWK, Graham
  11622.  
  11623. -Everyone is entitled to their opinion, no matter how wrong they may be...
  11624. - ------------------------------------------------------------------------
  11625.  
  11626. +++++++++++++++++++++++++++
  11627.  
  11628. >From Tony Myles <tony.myles@3do.com>
  11629. Date: 1 Mar 1994 22:55:29 GMT
  11630. Organization: The 3DO Company
  11631.  
  11632. In article <u9119523-010394182204@case1.sys.uea.ac.uk> Graham Cox,
  11633. u9119523@sys.uea.ac.uk writes:
  11634. >If you're the type who likes to reinvent the wheel, (like we all are at
  11635. >times!) then go ahead and don't let me stop you. 
  11636. >
  11637. >BUT- this has already been done- "SpriteWorld" (archive sites) works
  11638. >identically to the way you describe, with a pair of offscreen work areas.
  11639. >It generates sprites from PICT or cicn resources, and uses the time
  11640. manager
  11641. >to give sub-tick accuracy. It also has hooks for writing custom blitting
  11642. >routines, and comes with one for 8-bit colour direct screen blitting, or
  11643. >can use CopyBits. The example program turned in something like 100
  11644. >frames/sec on a Centris 610 animating 5 or 6 50 x 50 pixel sprites. I got
  11645. >64 frames/sec on my IIsi! It also has full layer support and collision
  11646. >detection. It is stable and easy to use- I rolled it into one of my C
  11647. >applications in one evening and never had the slightest trouble compiling
  11648. >it.
  11649.  
  11650. There will be a new version of SpriteWorld out soon. I have sped it up
  11651. about 20-30% using the custom blitter, and about 20% more on top of that
  11652. using compiled sprites. Numerous bug fixes were rolled in as well.
  11653.  
  11654. >Now I have SpriteWorld, I am never going to write another
  11655. sprite-animation
  11656. >routine again!
  11657. >
  11658. >I would also say that I have nothing whatsoever to do with its author,
  11659. but
  11660. >I am one very satisfied "customer" -and word-of-mouth advertising is the
  11661. >best kind!
  11662.  
  11663. Thanks, this is good to hear. Any chance of a SpriteWorld based version
  11664. of Desk Invaders?
  11665.  
  11666. >A technical point- SpriteWorld uses linked lists to store the data for
  11667. each
  11668. >sprite, not arrays. I wonder which method is faster? I reckon that the
  11669. >performance is not bound by this anyway, but on the number of pixels
  11670. >blitted per frame. SpriteWorld seems to go to a lot of trouble to
  11671. minimise
  11672. >the number of pixels blitted per frame, adding a little code overhead to
  11673. >check this, but its high performance seems to suggest that this is a good
  11674. >strategy.
  11675.  
  11676. Early versions of SpriteWorld used arrays, when I switched to doubly
  11677. linked lists it made no difference (for better or worse) in terms of
  11678. speed but it did greatly increase flexibility. 
  11679. As far as code overhead goes, I have found that almost anything you can
  11680. do to reduce the number of pixels you have to move, results in a faster
  11681. frame rate. During the development of SpriteWorld this has proved true in
  11682. almost all cases. However, when optimizing any algorithm, you have to
  11683. keep in mind the most common case. Take for example the case of
  11684. overlapping sprites. You might go to a lot of trouble to avoid blitting
  11685. the overlapping areas of the screen more than once per frame, but if your
  11686. sprites don't overlap much (or at all) this doesn't make sense. The
  11687. overhead of calculating the difference of the overlapping rects would
  11688. just slow down the most common case. For something like SpriteWorld, this
  11689. is particularly tricky, since I don't know for sure what the most common
  11690. case will be. Indeed, there is a danger of optimizing for the most common
  11691. case too much, to where the code is no longer good for anything BUT the
  11692. most common case (which may be OK, again depending on the application).
  11693. Inevitably it becomes a question of a tradeoffs between application
  11694. specific optimizations, and code generality and reusability.
  11695.  
  11696. ...Tony
  11697. - ---------------------------------------------
  11698. Tony Myles             work: tony.myles@3do.com
  11699. The 3DO Company        home: suiryu@aol.com
  11700.  
  11701. +++++++++++++++++++++++++++
  11702.  
  11703. >From deweeset@ptolemy1.rdrc.rpi.edu (Thomas E. DeWeese)
  11704. Date: 1 Mar 1994 20:52:02 GMT
  11705. Organization: Rensselaer Polytechnic Institute, Troy NY, USA
  11706.  
  11707. In article <1994Feb27.234911.14595@afterlife.ncsc.mil>,
  11708. M. Scott Smith <mssmith@afterlife.ncsc.mil> wrote:
  11709. >Ramble alert!  (This one's kinda long..)
  11710.  
  11711. >   I've been developing a direct-screen animation toolkit which I'll
  11712. >(eventually) be using to write games.  I'm now working on the "animation
  11713. >engine" -- the heart of the game where all of the animation will be
  11714. >performed.
  11715.  
  11716. >   The type of game I'll be writing will probably be similar to Lemmings,
  11717. >in that I need to have support for lots of (fairly small) sprites.  Having
  11718. >30 separate sprites on screen and moving is not too much to ask.  (It may
  11719. >be too much to program, but...)  But they'll generally be 32x32 pixels or
  11720. >smaller, with room for a few larger ones.  I'll write this game to fill
  11721. >the 12" monitor -- 512x384 pixels.  It will only support color, probably
  11722. >require System 7, etc.  And it uses "direct-screen" drawing; filling the
  11723. >video RAM with bytes for instant gratification.
  11724.     Just a note, 30 32x32 sprites in a 512x384 window is pretty
  11725. crowded (in my opinion).  
  11726.  
  11727. >   But (at least) two things bother me: there's two copies of 512x384 bytes
  11728. >occurring for each frame of animation: first the copy of the background
  11729. >into the work buffer, then the copy of the work buffer to the screen.  Not
  11730. >to mention all the copies of the sprites -- possibly up to 30.
  11731.  
  11732.     Yes this is a problem.  I strongly suggest the 'dirty'
  11733. rectangle solution propsed by so many others.  Using an insertion sort
  11734. to order them top to bottom, left to right shouldn't be so bad, for
  11735. only 30-60 elems.
  11736.  
  11737. >game's I/O and logic, etc.  I don't think a bad prediction would be that
  11738. >with those results, I might end up with around 6 frames per second.  Isn't
  11739. >that pretty bad?
  11740.     Yes, as others have noted 20-30fps is where you want to be.
  11741.  
  11742.  
  11743. As for your code:
  11744.     Keep your pixmap locked down, actually it doesn't matter too
  11745. much for this function since you can't cause a handle to move.
  11746.     Don't mess up a nice tight function with stuff like:
  11747.           if (data_allocated == 1)
  11748.     Test it once before you start blitting.  
  11749.  
  11750.     This should give you a pretty good starting place to start
  11751. optomizing your asm. The following is off the top of my head so it
  11752. might not compile.
  11753.  
  11754.  
  11755. long rowBytesDiv4;  /* row bytes divided by 4 (or >> 2 if your smart) */
  11756.  
  11757. void
  11758. Sprite::Plot(register long x, register long y)
  11759. {
  11760.   register long    *longPtr, *longPtr2;
  11761.   register long *endLn, *endImg;
  11762.   register long rowOffset = rowBytesDiv4 - width;  /* possibly precomputed */
  11763.  
  11764.  longPtr2 = (long *)(*theData);
  11765.  endImg = longPtr2+width*height;
  11766.  
  11767.  longPtr = (long *)(x + theScreen->line_ptr[y]);
  11768.  
  11769.  while (longPtr2<endImg)
  11770.    {
  11771.      longPtr += rowOffset;
  11772.      endLn = longPtr+width;
  11773.      while (longPtr<endLn)
  11774.        *longPtr++ = *longPtr2++;  /* if width is known unroll this using
  11775.                            * 68000 post increment stuff, and movem
  11776.                    */
  11777.    }
  11778. }
  11779.  
  11780. >   (How would CopyBits compare?)
  11781.     CopyBits has a fair amount of over head so for small blits it
  11782. loses (it needs to check colorTables, bit depths, clipRgns, and all
  11783. that junk) But once it get's going you won't be able to beat it.  So
  11784. for large general area copies you can only hope to match it's speed.
  11785. But for small known size areas you can cream it.
  11786.     BTW the above code won't get you any closer to animating
  11787. 512x384 at 30fps (if it did, we'd have Sonic THH on the market by
  11788. now), it will make it possible to animate your 32x32 icons at a reasonable
  11789. speed if you use a dirty rectangle scheme.  Also don't forget your basic
  11790. math.  If your sprite moves < 13 pixes blit one rectangle that encloses both
  11791. the new, and old location (45x45 = 2025 pixles, 32x32x2 = 2048 pixels).
  11792.  
  11793.     +-----+                     +--------+
  11794.     |##+-----+                    |#####   | one larger blit
  11795.     |##|.....| two 32x32 blits            |##......|
  11796.     +--|.....|                    |  ......|
  11797.            +-----+                    +--------+
  11798.  
  11799.     There is a trade off in that fixed size blits will be faster,
  11800. due to loop unrolling etc... than a variable sized loop (so you might
  11801. try haveing fixed width, and variable height, so the width is unrolled
  11802. and the height isn't.  You might have a function for widths of 32, 36,
  11803. 40, and 44.  You could then have an array of function pointers for
  11804. dispatching appropriately.
  11805.  
  11806. -- 
  11807.  
  11808. Thomas DeWeese         "If it helps you, just think of people using swear 
  11809. deweeset@rdrc.rpi.edu   words as truck drivers on the Information Superhighway"
  11810.                              -- Matthias Neeracher
  11811.  
  11812. +++++++++++++++++++++++++++
  11813.  
  11814. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  11815. Date: 2 Mar 1994 10:40:16 GMT
  11816. Organization: Royal Institute of Technology, Stockholm, Sweden
  11817.  
  11818. In <2l09tj$4i9@usenet.rpi.edu> deweeset@ptolemy1.rdrc.rpi.edu (Thomas E. DeWeese) writes:
  11819.  
  11820. >long rowBytesDiv4;  /* row bytes divided by 4 (or >> 2 if your smart) */
  11821.  
  11822. >>2 isn't very smart. It has strange semantics (precedence, signed/unsigned
  11823. etc) as well as is harder to read than a simple /4.
  11824.  
  11825. If your compiler doesn't generate a fast shift instead of a slow compile,
  11826. you have MUCH worse optimizations to worry about than hand-coding the
  11827. shift.
  11828.  
  11829. -- 
  11830.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  11831.   "It was, in fact, cool as all get-out.  Fortunately it was a little
  11832.    too late (historically speaking) to be groovy."
  11833.                      -- Dennis Pelton
  11834.  
  11835. +++++++++++++++++++++++++++
  11836.  
  11837. >From andrewwelc@aol.com (AndrewWelc)
  11838. Date: 2 Mar 1994 05:23:04 -0500
  11839. Organization: America Online, Inc.
  11840.  
  11841. >>
  11842. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11843. identically to the way you describe, with a pair of offscreen work areas.
  11844. <<
  11845. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11846. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11847. it.
  11848.  
  11849. The custom drawing routine just aren't all that optimized -- I recommend
  11850. writing your own if you plan to animate a reasonable number of sprites on
  11851. lower-end machines.  For the PowerPC, just use CopyBits().
  11852.  
  11853. Andrew
  11854.  
  11855. +++++++++++++++++++++++++++
  11856.  
  11857. >From andrewwelc@aol.com (AndrewWelc)
  11858. Date: 2 Mar 1994 05:23:07 -0500
  11859. Organization: America Online, Inc.
  11860.  
  11861. >>
  11862. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11863. identically to the way you describe, with a pair of offscreen work areas.
  11864. <<
  11865. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11866. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11867. it.
  11868.  
  11869. The custom drawing routine just aren't all that optimized -- I recommend
  11870. writing your own if you plan to animate a reasonable number of sprites on
  11871. lower-end machines.  For the PowerPC, just use CopyBits().
  11872.  
  11873. Andrew
  11874.  
  11875. +++++++++++++++++++++++++++
  11876.  
  11877. >From andrewwelc@aol.com (AndrewWelc)
  11878. Date: 2 Mar 1994 05:23:08 -0500
  11879. Organization: America Online, Inc.
  11880.  
  11881. >>
  11882. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11883. identically to the way you describe, with a pair of offscreen work areas.
  11884. <<
  11885. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11886. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11887. it.
  11888.  
  11889. The custom drawing routine just aren't all that optimized -- I recommend
  11890. writing your own if you plan to animate a reasonable number of sprites on
  11891. lower-end machines.  For the PowerPC, just use CopyBits().
  11892.  
  11893. Andrew
  11894.  
  11895. +++++++++++++++++++++++++++
  11896.  
  11897. >From andrewwelc@aol.com (AndrewWelc)
  11898. Date: 2 Mar 1994 05:23:05 -0500
  11899. Organization: America Online, Inc.
  11900.  
  11901. >>
  11902. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11903. identically to the way you describe, with a pair of offscreen work areas.
  11904. <<
  11905. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11906. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11907. it.
  11908.  
  11909. The custom drawing routine just aren't all that optimized -- I recommend
  11910. writing your own if you plan to animate a reasonable number of sprites on
  11911. lower-end machines.  For the PowerPC, just use CopyBits().
  11912.  
  11913. Andrew
  11914.  
  11915. +++++++++++++++++++++++++++
  11916.  
  11917. >From andrewwelc@aol.com (AndrewWelc)
  11918. Date: 2 Mar 1994 05:23:16 -0500
  11919. Organization: America Online, Inc.
  11920.  
  11921. >>
  11922. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11923. identically to the way you describe, with a pair of offscreen work areas.
  11924. <<
  11925. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11926. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11927. it.
  11928.  
  11929. The custom drawing routine just aren't all that optimized -- I recommend
  11930. writing your own if you plan to animate a reasonable number of sprites on
  11931. lower-end machines.  For the PowerPC, just use CopyBits().
  11932.  
  11933. Andrew
  11934.  
  11935. +++++++++++++++++++++++++++
  11936.  
  11937. >From andrewwelc@aol.com (AndrewWelc)
  11938. Date: 2 Mar 1994 05:23:18 -0500
  11939. Organization: America Online, Inc.
  11940.  
  11941. >>
  11942. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11943. identically to the way you describe, with a pair of offscreen work areas.
  11944. <<
  11945. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11946. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11947. it.
  11948.  
  11949. The custom drawing routine just aren't all that optimized -- I recommend
  11950. writing your own if you plan to animate a reasonable number of sprites on
  11951. lower-end machines.  For the PowerPC, just use CopyBits().
  11952.  
  11953. Andrew
  11954.  
  11955. +++++++++++++++++++++++++++
  11956.  
  11957. >From andrewwelc@aol.com (AndrewWelc)
  11958. Date: 2 Mar 1994 05:23:12 -0500
  11959. Organization: America Online, Inc.
  11960.  
  11961. >>
  11962. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11963. identically to the way you describe, with a pair of offscreen work areas.
  11964. <<
  11965. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11966. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11967. it.
  11968.  
  11969. The custom drawing routine just aren't all that optimized -- I recommend
  11970. writing your own if you plan to animate a reasonable number of sprites on
  11971. lower-end machines.  For the PowerPC, just use CopyBits().
  11972.  
  11973. Andrew
  11974.  
  11975. +++++++++++++++++++++++++++
  11976.  
  11977. >From andrewwelc@aol.com (AndrewWelc)
  11978. Date: 2 Mar 1994 05:23:13 -0500
  11979. Organization: America Online, Inc.
  11980.  
  11981. >>
  11982. BUT- this has already been done- "SpriteWorld" (archive sites) works
  11983. identically to the way you describe, with a pair of offscreen work areas.
  11984. <<
  11985. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  11986. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  11987. it.
  11988.  
  11989. The custom drawing routine just aren't all that optimized -- I recommend
  11990. writing your own if you plan to animate a reasonable number of sprites on
  11991. lower-end machines.  For the PowerPC, just use CopyBits().
  11992.  
  11993. Andrew
  11994.  
  11995. +++++++++++++++++++++++++++
  11996.  
  11997. >From andrewwelc@aol.com (AndrewWelc)
  11998. Date: 2 Mar 1994 05:23:15 -0500
  11999. Organization: America Online, Inc.
  12000.  
  12001. >>
  12002. BUT- this has already been done- "SpriteWorld" (archive sites) works
  12003. identically to the way you describe, with a pair of offscreen work areas.
  12004. <<
  12005. Sure -- SpriteWorld is good architecture (if you aren't going to do anything
  12006. with scrolling backgrounds, etc.), but in terms of raw animation speed, forget
  12007. it.
  12008.  
  12009. The custom drawing routine just aren't all that optimized -- I recommend
  12010. writing your own if you plan to animate a reasonable number of sprites on
  12011. lower-end machines.  For the PowerPC, just use CopyBits().
  12012.  
  12013. Andrew
  12014.  
  12015. +++++++++++++++++++++++++++
  12016.  
  12017. >From Tony Myles <tony.myles@3do.com>
  12018. Date: 2 Mar 1994 18:15:58 GMT
  12019. Organization: The 3DO Company
  12020.  
  12021. In article <2l1pe8$ehi@rmg01.prod.aol.net> AndrewWelc, andrewwelc@aol.com
  12022. writes:
  12023. >Sure -- SpriteWorld is good architecture (if you aren't going to do
  12024. anything
  12025. >with scrolling backgrounds, etc.), but in terms of raw animation speed,
  12026. forget
  12027. >it.
  12028.  
  12029. Forget it? Oooh, that stings. ;-)
  12030.  
  12031. >The custom drawing routine just aren't all that optimized -- I recommend
  12032. >writing your own if you plan to animate a reasonable number of sprites on
  12033. >lower-end machines.
  12034.  
  12035. So do I.  I have improved the blitters in SpriteWorld about 20%, but they
  12036. were really never intended to be used as is. They more or less serve as
  12037. examples, so that you can write your own that are more specific to your
  12038. animation. (ie. assuming 32x32 sprites or whatever).
  12039.  
  12040. >For the PowerPC, just use CopyBits().
  12041.  
  12042. Decide to give up on your PowerPC sprite compiler, Andrew?
  12043.  
  12044. ...Tony
  12045. - ---------------------------------------------
  12046. Tony Myles             work: tony.myles@3do.com
  12047. The 3DO Company        home: suiryu@aol.com
  12048.  
  12049. +++++++++++++++++++++++++++
  12050.  
  12051. >From al@crucible.powertools.com (Al Evans)
  12052. Date: 2 Mar 94 19:15:31 GMT
  12053. Organization: PowerTools, Austin, Texas
  12054.  
  12055. In another article in this thread (which has unfortunately expired from
  12056. my news spool), John Werner (john_werner@taligent.com) suggested a
  12057. strategy of dividing up the background into a grid of rectangles to limit
  12058. the amount of drawing that would be required for each update.
  12059.  
  12060. Since this kind of thing is easy to implement in Graphic Elements (took
  12061. me 26 lines of code, boast boast), I ran some tests. In these tests,
  12062. a) the moving graphics were 42 X 42 pixels, and b) the background
  12063. which was updated in any particular cell was the union of the rects
  12064. of all changed graphics in that cell. I used two different sets of
  12065. test conditions. 
  12066.  
  12067. In the first test, the graphics were all in two even lines, moving to the 
  12068. right to the edge of the window, then dropping down half their height
  12069. and moving to the left. When they hit the bottom of the window, they 
  12070. moved back to the top left corner.
  12071.  
  12072. Using 16 of these graphics on a Quadra 800, I found that the frame
  12073. rate varied from 60 to 71 fps when the background was a single
  12074. cell. This is explained by the fact that when a graphic on the
  12075. bottom right "dropped off" to the top left, almost the entire 
  12076. background (512 X 384) was included in the update. 
  12077.  
  12078. A few quick tests indicated that the optimum dimensions for the
  12079. background grid were about 3X the "sprite" size. Dividing the
  12080. background into 128X128 cells gave me frame rates of 63 to 68
  12081. fps -- not as high on the high end because of the increased 
  12082. overhead of processing 12 background elements instead of 1,
  12083. but better on the low end. The improvement in the "look" of the 
  12084. movement was better than the figures would indicate, since these 
  12085. are average frame rates over 30 seconds.
  12086.  
  12087. This technique really shone, though, when the graphics were in
  12088. random motion over the background. For the same 16 graphics, I
  12089. got an average of 46 fps using the 128X128 cells, as compared
  12090. to 39 fps using a single background cell. And the difference
  12091. increased as the number of graphics dropped: 80 fps as compared
  12092. to 60 with 8 graphics, 175 as compared to 96 with 4. Once
  12093. again, the "look" was greatly improved.
  12094.  
  12095. I'm sure that's more than you ever wanted to know. But I've found
  12096. that it's very difficult to predict the effect of an "improvement"
  12097. in a high-performance animation system, and thought I'd share these
  12098. numbers since I'm in a position to do so.
  12099.  
  12100.                     --Al Evans--
  12101. -- 
  12102.  
  12103. Al Evans                         Tu causes, tu causes
  12104. al@crucible.powertools.com               C'est tout ce que tu sais faire
  12105. cs.utexas.edu!crucible!al                     -- LaVerdure
  12106.  
  12107. +++++++++++++++++++++++++++
  12108.  
  12109. >From mxmora@unix.sri.com (Matt Mora)
  12110. Date: 2 Mar 1994 13:28:29 -0800
  12111. Organization: SRI International, Menlo Park, CA
  12112.  
  12113. In article <421@crucible.powertools.com> al@crucible.powertools.com (Al Evans) writes:
  12114.  
  12115. >I'm sure that's more than you ever wanted to know. But I've found
  12116. >that it's very difficult to predict the effect of an "improvement"
  12117. >in a high-performance animation system, and thought I'd share these
  12118. >numbers since I'm in a position to do so.
  12119.  
  12120. Can you post the code? It would be cool to try it on other macs to see
  12121. how things differ.
  12122.  
  12123.  
  12124.  
  12125. Xavier
  12126.  
  12127.  
  12128. -- 
  12129. ___________________________________________________________
  12130. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  12131. SRI International                       mxmora@unix.sri.com
  12132. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  12133.  
  12134. +++++++++++++++++++++++++++
  12135.  
  12136. >From ua025@freenet.Victoria.BC.CA (Cody Jones)
  12137. Date: Fri, 4 Mar 1994 10:37:46 GMT
  12138. Organization: The Victoria Freenet Association (VIFA), Victoria, B.C., Canada
  12139.  
  12140.  
  12141. I'll just put in my 2 bits... I'm also doing a game w/ direct-screen
  12142. writing, a fair number of 32x32 sprites, etc... I ONLY use direct writing
  12143. because I've had it with letting the system do it for me.  Besides, my
  12144. game will have a MOD playing so my code needs all the speed it can get.
  12145.  
  12146. Anyway, a suggestion: Try and make use of the 68040's MOVE16 command. 
  12147. You might keep an array of flags, one for each row on the screen.  If the
  12148. row is set, update it - the entire row, that is.  The MOVE16 will probably
  12149. be fast enough to compensate for copying what you don't need to on each
  12150. line: on my Tempest (aka. 660AV) I was able to move over 80 megs/second
  12151. with it!  For a 512x384 screen, you can sure get a decent frame rate with
  12152. that - well, well over 60 fps.
  12153.  
  12154. I haven't actually implemented this 'row updating' idea, only a routine to
  12155. test the MOVE16's speed.  Of course this method won't work on 68030's...
  12156. your program would have to check & call the proper update-routine
  12157. according to the processor.
  12158.  
  12159. Cody Jones of Zerius Development
  12160. ua025@freenet.victoria.bc.ca
  12161.  
  12162. -- 
  12163.  
  12164. +++++++++++++++++++++++++++
  12165.  
  12166. >From andrewwelc@aol.com (AndrewWelc)
  12167. Date: 4 Mar 1994 10:32:04 -0500
  12168. Organization: America Online, Inc.
  12169.  
  12170. >>
  12171. I haven't actually implemented this 'row updating' idea, only a routine to
  12172. test the MOVE16's speed.  Of course this method won't work on 68030's...
  12173. your program would have to check & call the proper update-routine
  12174. according to the processor.
  12175. <<
  12176. I'm curious what other nitty gritty write-directly-to-the-screen-in-assmebler
  12177. game programmers out there (like me) are doing for the PowerPC....?
  12178.  
  12179. Andrew Welch
  12180. Ambrosia Software
  12181.  
  12182.  
  12183. +++++++++++++++++++++++++++
  12184.  
  12185. >From Ron_Hunsinger@bmug.org
  12186. Date: Tue, 01 Mar 1994 15:37:18 PST
  12187. Organization: BMUG, Inc.
  12188.  
  12189. M. Scott Smith,mssmith@afterlife.ncsc.mil writes:
  12190.  
  12191. >   But (at least) two things bother me: there's two copies of 512x384 bytes
  12192. >occurring for each frame of animation: first the copy of the background
  12193. >into the work buffer, then the copy of the work buffer to the screen.  Not
  12194. >to mention all the copies of the sprites -- possibly up to 30.
  12195.  
  12196. That worries me too.  (I developed a sprite engine on the Plus, and ran
  12197. into the same kinds of problems you're running into.)
  12198.  
  12199. >  No optimizations:356 frames / 30 seconds or 11.87 frames/s
  12200. >  Compiled for 68020 and up,
  12201. >    with all Symantec C++ opts: 554 frames / 30 seconds or 18.47 frames/s
  12202.  
  12203. And this is the main problem, in a nutshell.  Even on a B/W 512x342 screen,
  12204. there just isn't time to be copying screen-sized data around.  The Plus
  12205. simply didn't have that kind of horsepower, and if you are running on
  12206. a faster machine you are probably using color and/or a bigger screen, and
  12207. the problem is still there.  Probably will always be there, because I
  12208. see no reason for the screenSize:processorPower ratio to change much.
  12209.  
  12210. >   I know there are probably ways to prevent copying the entire screen,
  12211. >and I could use some suggestions.  I could keep track of a "dirty rectangle"
  12212. >that needs updating, but for my game I'll have sprites all over the screen
  12213. >so it seems like I'll need to copy the whole screen anyway.  Keeping a
  12214. >list of rectangles needing to be copied is another possibility, but this
  12215. >will result in a lot of overhead and required computations, and numerous
  12216. >little copies that would probably make it slower.
  12217.  
  12218. I used the "dirty rectangle" approach, but NOT by keeping a separate 
  12219. rectangle for each sprite.  Remember, you're trying to minimize copying,
  12220. so you don't want to copy the data twice if two sprites overlap.
  12221.  
  12222. Instead, I divided the screen into a bunch of rectangular zones, each
  12223. rectangular and nicely aligned.  In my case, I made the zones 16x16
  12224. pixels, so that the entire screen was like 32x20 zones.  (For an
  12225. effective screen size of 512x320 pixels, meaning I discarded 22 pixels
  12226. in the vertical dimension.)  Then I kept track of which zones were
  12227. dirty, using a table of 20 longwords.  You might call this the "dirty
  12228. zone" method.
  12229.  
  12230. Taking the union of draw lists becomes a snap.  (You have to update not 
  12231. only the zones where the sprites are now, but also the zones where they 
  12232. were last time.)  Just keep two dirty zone lists: one for the work area,
  12233. to keep track of which zones differ from the background; and one for the
  12234. screen, for all the zones that need to be updated from the work area.
  12235.  
  12236. When I actually copied the data to the screen, I walked the dirty zone
  12237. table, and copied each dirty zone directly to the screen using 16 
  12238. consecutive MOVE.W instructions.  Remember, I was doing this on a Plus, 
  12239. which had a 16-bit data bus and no cache.  (At the time, color and the 
  12240. Mac II were only rumors.)  
  12241.  
  12242. I was able to get 30 frames per second on a Plus, with a few hundred
  12243. sprites moving on the screen at once.  Looked nice.  Since the zones get 
  12244. updated in top-to-bottom order, I got no flicker even though I made no
  12245. effort to synchronize with vertical retrace.
  12246.  
  12247. If I were to do it again, I would use larger zones, keeping them 
  12248. longword aligned but large enough so that the width of the screen would 
  12249. still not exceed 32 zones.  And although writing directly to the screen 
  12250. is faster, I think now I would seriously consider using CopyBits for the 
  12251. final copy.  I did not appreciate at the time how fragile direct screen 
  12252. manipulation makes your program.  I would probably try to combine 
  12253. horizontally adjacent zones into a single CopyBits call, to minimize
  12254. CopyBit's setup overhead.
  12255.  
  12256. -Ron Hunsinger
  12257.  
  12258.  
  12259.  
  12260. +++++++++++++++++++++++++++
  12261.  
  12262. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  12263. Date: Sun, 6 Mar 1994 01:30:05 GMT
  12264. Organization: The Great Beyond
  12265.  
  12266. Hi gang!
  12267.  
  12268.    I want to extend a very loud "thank you!" to everyone for their messages
  12269. concerning speeding up my animation.
  12270.  
  12271.    A week or so ago, I brainstormed out loud about a method for doing smooth
  12272. animation in a game that might potentially have a lot of small sprites.  The
  12273. easiest method I could think of was to keep two offscreen buffers, one a
  12274. "background" buffer (always containing the pure background) and another a
  12275. "work" buffer, where I would copy the background and then stick sprites on.
  12276. Finally, I would copy from the work buffer to the screen.
  12277.  
  12278.    But my suggested method (while certainly easiest) of copying the entire
  12279. buffer first from background to work area, and then work area to screen,
  12280. was, by my own testing, slow on a IIfx in 8-bit.  I asked for any
  12281. suggestions, including whether or not "dirty rectangle" approaches would
  12282. be faster.  I also posted some code and asked for suggestions on
  12283. optimization.
  12284.  
  12285.    Well, dozens of people responded on the net and in e-mail, and every 
  12286. single comment I received was of great help.
  12287.  
  12288.    First, people made code-level suggestions for squeezing more speed out
  12289. of my algorithm, and I learned some new optimizing techniques that I'll
  12290. be using from now on.
  12291.  
  12292.    The general concensus seems to be that the best approach to updating the
  12293. screen as quick as possible is to use "dirty rectangles" or "dirty zones."
  12294. In some way, maintain areas which you can flag as "dirty" (meaning they
  12295. have had activity that requires updating).  While I pondered over whether or
  12296. not this might be slow -- after all, maintaing such a list can require quite
  12297. a few operations -- people said that it will almost always be less expensive
  12298. than copying all of the data in an entire screen.  And that makes sense to
  12299. me now.  Efficient methods of maintaining such lists were presented.
  12300.  
  12301.    I was reminded that libraries such as SpriteWorld exist and already do
  12302. much of what I want, but I don't mind "reinventing the wheel" because this
  12303. is a learning experience for me.  (This is the same reason I don't use
  12304. MacApp or TCL but instead write my own class libraries; I may not do it
  12305. as well, but I learn how it's done.  Maybe that's stubborn, but as a kid
  12306. I took everything apart to see how it works; I don't like "black boxes."
  12307. Once I learn how to develop my own class libraries, I'll be happy to use
  12308. other ones since I'll have an idea of how they were written.)
  12309.  
  12310.    I really like the kind of discussion that has been going on in this
  12311. thread; it's thought-provoking.  It'd be great if it could continue;
  12312. there's lots of general issues involved in game writing which are a little
  12313. abstract.
  12314.  
  12315. - -[fade out, fade in..]---
  12316.  
  12317.    One of the other things that has been eating at me is the best way to
  12318. handle "timing."  The best method will be to make the animation machine-
  12319. independent.  If a sprite is moving across the screen at a certain speed
  12320. on the PowerMac's, it should move at the same speed on an LC.  This may
  12321. mean skipping frames in the animation -- or moving the sprite along 4
  12322. pixels at a time instead of 2.
  12323.  
  12324.    I've mulled over this one a bit, but haven't come up with anything
  12325. that I'm particularly thrilled about.  Any suggestions?
  12326.  
  12327.    And on another note entirely, say you have some type of "animated
  12328. background."  Such as a flaming torch on the wall of a castle.  The
  12329. flame flickers and throws out dancing light along the wall.  But it's
  12330. always in the background -- it's animated just like sprites, but it
  12331. doesn't interact with the (foreground) sprites.
  12332.  
  12333.    Something I briefly tried some time ago was putting the code for
  12334. these types of animations in background tasks.  Is this more trouble
  12335. than it's worth?  (Is it better to handle all of the animation in the
  12336. same place?)
  12337.  
  12338. Thanks again for all the help..
  12339.  
  12340. Scott
  12341.  
  12342. - -
  12343. M. Scott Smith    (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu)
  12344.  
  12345.   Macintosh developer. Student. Ski bum.  Eater of Ben and Jerry's ice cream.
  12346.  
  12347.  
  12348. +++++++++++++++++++++++++++
  12349.  
  12350. >From ua025@freenet.Victoria.BC.CA (Cody Jones)
  12351. Date: Sun, 6 Mar 1994 02:26:26 GMT
  12352. Organization: The Victoria Freenet Association (VIFA), Victoria, B.C., Canada
  12353.  
  12354.  
  12355. "   One of the other things that has been eating at me is the best way to
  12356. handle "timing."  The best method will be to make the animation machine-
  12357. independent.  If a sprite is moving across the screen at a certain speed
  12358. on the PowerMac's, it should move at the same speed on an LC.  This may
  12359. mean skipping frames in the animation -- or moving the sprite along 4
  12360. pixels at a time instead of 2."
  12361.  
  12362. One way I use is this:  Keep track of the last time your update routine
  12363. was called.  When you get to the update again, see how many ticks have
  12364. passed, and for each one, call your update routine.  Thus your rout always
  12365. gets called 60 times a second... well, kind of.
  12366. After that you output the frame.  This method has the advantage you are
  12367. looking for.  No matter how bad the fps rate, objects always move at the
  12368. same rate.
  12369.  
  12370. Cody Jones, Zerius Development
  12371. ua025@freenet.victoria.bc.ca
  12372. voltaire@amtsgi.bc.ca
  12373.  
  12374. -- 
  12375.  
  12376. +++++++++++++++++++++++++++
  12377.  
  12378. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  12379. Date: Sun, 6 Mar 1994 11:48:05 GMT
  12380. Organization: Demon Internet
  12381.  
  12382.  
  12383. >    One of the other things that has been eating at me is the best way to
  12384. > handle "timing."  The best method will be to make the animation machine-
  12385. > independent.  If a sprite is moving across the screen at a certain speed
  12386. > on the PowerMac's, it should move at the same speed on an LC.  This may
  12387. > mean skipping frames in the animation -- or moving the sprite along 4
  12388. > pixels at a time instead of 2.
  12389. >    I've mulled over this one a bit, but haven't come up with anything
  12390. > that I'm particularly thrilled about.  Any suggestions?
  12391. >    And on another note entirely, say you have some type of "animated
  12392. > background."  Such as a flaming torch on the wall of a castle.  The
  12393. > flame flickers and throws out dancing light along the wall.  But it's
  12394. > always in the background -- it's animated just like sprites, but it
  12395. > doesn't interact with the (foreground) sprites.
  12396. >    Something I briefly tried some time ago was putting the code for
  12397. > these types of animations in background tasks.  Is this more trouble
  12398. > than it's worth?  (Is it better to handle all of the animation in the
  12399. > same place?)
  12400. > Thanks again for all the help..
  12401. > Scott
  12402.  
  12403.      In my game, I have a simple loop of game code, and I use quite simple
  12404. code to determine a standard game speed for all Macs:
  12405.  
  12406. {
  12407.      long tTicks;
  12408.  
  12409.      tTicks = TickCount ();
  12410.      GameLoop ();
  12411.      while (TickCount () - tTicks < kLoopSpeed);
  12412. }
  12413.  
  12414. where kLoopSpeed, on my game, is 2. I know this method isn't all that
  12415. accurate, but it's good enough for what I'm doing.
  12416.  
  12417.      As for the flickering torches idea... that shouldn't be a problem.
  12418. Just make the torch a sprite just like the others, but make sure that it's
  12419. one of the first ones copied across to your work area, before any of your
  12420. moving sprites are copied. That way, anything that passes "over it" will be
  12421. copied on top of it, and it will look like the torch is behind your main
  12422. (moving) sprites.
  12423.  
  12424.      Hope this helps,
  12425.  
  12426.  
  12427.  
  12428.      Alex
  12429.  
  12430. --
  12431. Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler
  12432.  
  12433. Internet, AOL, BIX:     alex@metcalf.demon.co.uk
  12434. AppleLink:              alex@metcalf.demon.co.uk@internet#
  12435. CompuServe:             INTERNET:alex@metcalf.demon.co.uk
  12436. Delphi:                 alex@metcalf.demon.co.uk@inet#
  12437. FirstClass:             alex@metcalf.demon.co.uk,Internet
  12438. Fax (UK):               (0570) 45636
  12439. Fax (US / Canada):      011 44 570 45636
  12440.  
  12441. +++++++++++++++++++++++++++
  12442.  
  12443. >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate)
  12444. Date: Sun, 6 Mar 1994 20:54:35 GMT
  12445. Organization: DCRT, NIH, Bethesda, MD
  12446.  
  12447. In article <alex-060394114457@metcalf.demon.co.uk>, alex@metcalf.demon.co.uk (Alex Metcalf) writes:
  12448. >Someone named Scott writes: (sorry; I lost the attribution!)
  12449. >> 
  12450. >>    One of the other things that has been eating at me is the best way to
  12451. >> handle "timing."  The best method will be to make the animation machine-
  12452. >> independent.  If a sprite is moving across the screen at a certain speed
  12453. >> on the PowerMac's, it should move at the same speed on an LC.  This may
  12454. >> mean skipping frames in the animation -- or moving the sprite along 4
  12455. >> pixels at a time instead of 2.
  12456. >> 
  12457. >>    I've mulled over this one a bit, but haven't come up with anything
  12458. >> that I'm particularly thrilled about.  Any suggestions?
  12459.  
  12460. >     In my game, I have a simple loop of game code, and I use quite simple
  12461. >code to determine a standard game speed for all Macs:
  12462. >
  12463. >{
  12464. >     long tTicks;
  12465. >
  12466. >     tTicks = TickCount ();
  12467. >     GameLoop ();
  12468. >     while (TickCount () - tTicks < kLoopSpeed);
  12469. >}
  12470. >
  12471. >where kLoopSpeed, on my game, is 2. I know this method isn't all that
  12472. >accurate, but it's good enough for what I'm doing.
  12473.  
  12474. Ack!  Phtui!
  12475.  
  12476. (Sorry; I got a little carried away.  :-)
  12477.  
  12478. This might be reasonable if your animation speed is high, but it *does*
  12479. have the unfortunate property that it locks up the rest of the machine
  12480. while waiting for an animation interval to pass.
  12481.  
  12482. Why not set up a simple Time Manager routine to set a flag somewhere
  12483. that means 'it's time to draw another animation step?'  This is
  12484. particularly nice in that you can have more than one Time Manager
  12485. routine that set different flags for different movement rates.  That
  12486. way, you don't need the movement rates to necessarily be integer
  12487. multiples of some base rate (other than the rate of traversal of the
  12488. main loop, of course).
  12489.  
  12490. Also, I *believe* that a Time Manager task doesn't take up any
  12491. execution time while it's pending - is this right?  I was of the impression
  12492. that a pending Time Manager task is just an entry in the task queue, 
  12493. until such time as the Time Manager decides it's time to call it.  If
  12494. this is the case, then you avoid any 'check to see if it's time yet'
  12495. overhead.
  12496.  
  12497. Furthermore (:-), this automatically gives you 'simulated' fixed-point
  12498. movement speeds - i.e. not integer numbers of pixels per step in any
  12499. given direction.  Not having integer pixels/step speeds goes a looooong
  12500. way towards making your animation look smooth, especially at lower object
  12501. movement speeds.
  12502.  
  12503. (Good luck, by the way!  And remember that the Time Manager is your friend!)
  12504.  
  12505. - --------------------------------------------------------------------------
  12506. Christopher Tate            |  "I hate writing, and I hate statistics, but
  12507. MSD, Inc.                   |   most of all I hate writing about statistics.
  12508.                             |   I'd rather go to the dentist; at least there
  12509. fixer@faxcsl.dcrt.nih.gov   |   you get to spit."     -- Ed Sewell
  12510.  
  12511. +++++++++++++++++++++++++++
  12512.  
  12513. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  12514. Date: Sun, 6 Mar 1994 23:15:50 GMT
  12515. Organization: Demon Internet
  12516.  
  12517. In article <1994Mar6.205435.229@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov
  12518. (Chris Gonna' Find Ray Charles Tate) wrote:
  12519.  
  12520. > In article <alex-060394114457@metcalf.demon.co.uk>, alex@metcalf.demon.co.uk (Alex Metcalf) writes:
  12521. > >Someone named Scott writes: (sorry; I lost the attribution!)
  12522. > >> 
  12523. > >>    One of the other things that has been eating at me is the best way to
  12524. > >> handle "timing."  The best method will be to make the animation machine-
  12525. > >> independent.  If a sprite is moving across the screen at a certain speed
  12526. > >> on the PowerMac's, it should move at the same speed on an LC.  This may
  12527. > >> mean skipping frames in the animation -- or moving the sprite along 4
  12528. > >> pixels at a time instead of 2.
  12529. > >> 
  12530. > >>    I've mulled over this one a bit, but haven't come up with anything
  12531. > >> that I'm particularly thrilled about.  Any suggestions?
  12532. > >     In my game, I have a simple loop of game code, and I use quite simple
  12533. > >code to determine a standard game speed for all Macs:
  12534. > >
  12535. > >{
  12536. > >     long tTicks;
  12537. > >
  12538. > >     tTicks = TickCount ();
  12539. > >     GameLoop ();
  12540. > >     while (TickCount () - tTicks < kLoopSpeed);
  12541. > >}
  12542. > >
  12543. > >where kLoopSpeed, on my game, is 2. I know this method isn't all that
  12544. > >accurate, but it's good enough for what I'm doing.
  12545. > Ack!  Phtui!
  12546. > (Sorry; I got a little carried away.  :-)
  12547. > This might be reasonable if your animation speed is high, but it *does*
  12548. > have the unfortunate property that it locks up the rest of the machine
  12549. > while waiting for an animation interval to pass.
  12550. > Why not set up a simple Time Manager routine to set a flag somewhere
  12551. > that means 'it's time to draw another animation step?'  This is
  12552. > particularly nice in that you can have more than one Time Manager
  12553. > routine that set different flags for different movement rates.  That
  12554. > way, you don't need the movement rates to necessarily be integer
  12555. > multiples of some base rate (other than the rate of traversal of the
  12556. > main loop, of course).
  12557.  
  12558.      Ack! Phtui!
  12559.  
  12560.      That's all fine and well, but if your game doesn't have an event loop
  12561. (as most arcade games don't, since it takes too much CPU time for
  12562. background processing), there's nothing else to do while you're waiting for
  12563. the next animation interval!
  12564.  
  12565.      But it's a good idea. :-)
  12566.  
  12567.      Alex
  12568.  
  12569. +++++++++++++++++++++++++++
  12570.  
  12571. >From s_heidri@iraul1.ira.uka.de (Dietmar Heidrich)
  12572. Date: 7 Mar 1994 13:58:31 GMT
  12573. Organization: University of Karlsruhe, FRG
  12574.  
  12575. In article <Arsenault_C-280294132621@134.33.101.226>, Arsenault_C@msm.cdx.mot.com (Chris Arsenault) writes:
  12576. |> Some comments:
  12577. [...]
  12578. |> - Do everything in your offscreen buffer then use CopyBits to move the
  12579. |> dirtyRect to screen...even if CopyBits has to make the transition to
  12580. |> different bit depths, chances are it will stay ahead of the electron gun
  12581. |> and you'll still get robust, smooth flicker-free animation and your game
  12582. |> will have a nice long life. (See Inside Mac III, p20. Although the values
  12583. |> are off, the ideas are still valid!)
  12584.  
  12585. I am no Mac programmer, but on other platforms you can switch video buffers
  12586. for games instead of copying everything you already have drawn.  Is there
  12587. no way to do that OS compliant on the Mac ?  I think CopyBits() will be too
  12588. slow for action games if you need to copy 640x480x8bit = 307200 bytes per
  12589. frame.  For 30 frames/s update rate, this yields 9 MB/s transfer rate eaten
  12590. up only for CopyBits().  Assuming you can transfer 16 bytes via burst (giving
  12591. 576000 bursts needed) in 20 clock cycles, this means 46% CPU time on a 25 MHz
  12592. 68040.
  12593.  
  12594.  
  12595.  
  12596. --
  12597. Dietmar Heidrich, Universitaet Karlsruhe, Germany
  12598.  
  12599.  
  12600. "Die Hoffnung auf den Tod ist das einzige, was mich am Leben erhaelt."
  12601.  
  12602. +++++++++++++++++++++++++++
  12603.  
  12604. >From rmah@panix.com (Robert S. Mah)
  12605. Date: Tue, 08 Mar 1994 01:29:01 -0500
  12606. Organization: One Step Beyond
  12607.  
  12608. s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) wrote:
  12609.  
  12610. > I am no Mac programmer, but on other platforms you can switch video buffers
  12611. > for games instead of copying everything you already have drawn.  Is there
  12612. > no way to do that OS compliant on the Mac ?  
  12613.  
  12614. Nope.
  12615.  
  12616. > I think CopyBits() will be too slow for action games if you need to copy
  12617. > 640x480x8bit = 307200 bytes per frame.  For 30 frames/s update rate, this
  12618. > [...]
  12619.  
  12620. Tell that to those who use CopyBits to write arcade games :-).  Seriouslly,
  12621. it's possible, it's just not easy.
  12622.  
  12623. Cheers,
  12624. Rob
  12625. ________________________________________________________________________
  12626.  Robert S. Mah              One Step Beyond              rmah@panix.com
  12627.  
  12628. +++++++++++++++++++++++++++
  12629.  
  12630. >From sigurasg@rhi.hi.is (Sigurdur Asgeirsson)
  12631. Date: 8 Mar 1994 11:25:16 GMT
  12632. Organization: University of Iceland
  12633.  
  12634. In <2lfbu7INN597@iraun1.ira.uka.de> s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) writes:
  12635.  
  12636. >In article <Arsenault_C-280294132621@134.33.101.226>, Arsenault_C@msm.cdx.mot.com (Chris Arsenault) writes:
  12637. [snip]
  12638. >I am no Mac programmer, but on other platforms you can switch video buffers
  12639. >for games instead of copying everything you already have drawn.  Is there
  12640. >no way to do that OS compliant on the Mac ?
  12641. [snip]
  12642.  
  12643.   There is a well defined way to do this for color-quickdraw capable
  12644. video devices. The video driver interface includes calls to check how
  12645. many video pages are available, find their baseaddresses and to switch
  12646. between video pages. It seems that this feature is little enough used
  12647. though that newer video cards don't bother to support multiple video
  12648. pages, even if they have the video RAM needed, the Quadras for instance
  12649. don't seem to support multiple video pages.
  12650. -- 
  12651. Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
  12652. Kambasel 26            | for instance declares f as an array of unspecified 
  12653. 109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
  12654. sigurasg@rhi.hi.is     | functions that return void... I think"
  12655.  
  12656. +++++++++++++++++++++++++++
  12657.  
  12658. >From mgleason@cse.unl.edu (Mike Gleason)
  12659. Date: 9 Mar 1994 02:09:38 GMT
  12660. Organization: NCEMRSoft
  12661.  
  12662. |s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) wrote:
  12663.  
  12664. |> I am no Mac programmer, but on other platforms you can switch video buffers
  12665. |> for games instead of copying everything you already have drawn.  Is there
  12666. |> no way to do that OS compliant on the Mac ?  
  12667.  
  12668. |Nope.
  12669.  
  12670. That's pretty depressing.  The Sega Genesis and Commodore Amiga, which
  12671. use the same damn 68000 in the Mac Plus I use, get phemomenal performance.
  12672. Ever play Sonic the Hedgehog?  That should be able to be done on a mac.
  12673. Hard to believe...  I think the Amiga uses a Screen pointer, which is
  12674. changeable by the programmer, so that to do very fast screen scrolling,
  12675. all you need to do is set the screen pointer to something else.  It makes
  12676. no sense to me that you have to re-copy the whole damn screen if all you
  12677. want to do is scroll the screen downward a pixel.
  12678.  
  12679. --
  12680. ______________________________________________________________________________
  12681. mike gleason                 mgleason@cse.unl.edu             NCEMRSoft, baby!
  12682.  
  12683. +++++++++++++++++++++++++++
  12684.  
  12685. >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault)
  12686. Date: Tue, 08 Mar 1994 12:35:30 -0500
  12687. Organization: Motorola Codex
  12688.  
  12689. In article <alex-060394231343@metcalf.demon.co.uk>,
  12690. alex@metcalf.demon.co.uk (Alex Metcalf) wrote:
  12691.  
  12692. >      That's all fine and well, but if your game doesn't have an event loop
  12693. > (as most arcade games don't, since it takes too much CPU time for
  12694. > background processing), there's nothing else to do while you're waiting for
  12695. > the next animation interval!
  12696.  
  12697. One of the things I do is to switch in and out of a main event loop.  When
  12698. running time critical game code I stay out of the main event loop, working
  12699. only with specific keypresses etc. When I see a special key (such as the
  12700. space bar) I switch in and out of the main event loop where I handle events
  12701. normally.  The nice part about this approach is I have very clean/fast
  12702. animation without background process relinquish jitters, but I can still
  12703. handle menus, application switching and the like.
  12704.  
  12705. BTW, when you're the foreground process you can tell the system that you
  12706. really want all the time you can by setting the WaitNextEvent sleep
  12707. parameter to 0.
  12708.  
  12709. Chris  
  12710.  
  12711. -- 
  12712. #include <UsualLegalDisclaimers.h>
  12713.  
  12714. +++++++++++++++++++++++++++
  12715.  
  12716. >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault)
  12717. Date: Tue, 08 Mar 1994 12:51:42 -0500
  12718. Organization: Motorola Codex
  12719.  
  12720. In article <2lfbu7INN597@iraun1.ira.uka.de>, s_heidri@iraul1.ira.uka.de
  12721. (Dietmar Heidrich) wrote:
  12722.  
  12723.  
  12724. > I am no Mac programmer, but on other platforms you can switch video buffers
  12725. > for games instead of copying everything you already have drawn.  Is there
  12726. > no way to do that OS compliant on the Mac ?  I think CopyBits() will be too
  12727. > slow for action games if you need to copy 640x480x8bit = 307200 bytes per
  12728. > frame.  For 30 frames/s update rate, this yields 9 MB/s transfer rate eaten
  12729. > up only for CopyBits().  Assuming you can transfer 16 bytes via burst (giving
  12730. > 576000 bursts needed) in 20 clock cycles, this means 46% CPU time on a 25 MHz
  12731. > 68040.
  12732.  
  12733. No. Not when focusing on market share.
  12734.  
  12735. You're right about video page flipping being CPU intensive.  That's why you
  12736. don't see a lot of Mac video games that do full frame (640x480) flipping
  12737. and if you do the frames are usually small (ever seen QuickTime movies
  12738. playing at full speed?).
  12739.  
  12740. Actually, there is a tradeoff involved. By using CopyBits we gain
  12741. simplicity in handling numerous video configurations and application
  12742. longevity.  What we lose is speed. We don't have a mode 13h or X. If we
  12743. draw using Toolbox trap calls to memory on a video card, then we have to
  12744. run over NuBus. (number of draw calls * (Trap dispatch overhead + NuBus
  12745. overhead + actual operation) = too expensive).
  12746.  
  12747. BTW - there are video cards out there that support several frame buffers
  12748. (GWorlds). But they are more likely to be found in high end publishing
  12749. systems than in the target game Mac - the LCIII.
  12750.  
  12751. IMHO, I would love to see hardware supported video DMA. I've worked with
  12752. the Amiga and it was great to have the blitter and copper. 
  12753. Chris
  12754.  
  12755. -- 
  12756. #include <UsualLegalDisclaimers.h>
  12757.  
  12758. +++++++++++++++++++++++++++
  12759.  
  12760. >From flavius@bga.com (Flavius Goombius)
  12761. Date: 9 Mar 1994 09:48:54 -0600
  12762. Organization: PowerTools, Austin, TX
  12763.  
  12764. In article <1994Mar6.013005.18429@afterlife.ncsc.mil>,
  12765. M. Scott Smith <mssmith@afterlife.ncsc.mil> wrote:
  12766.  
  12767. >   One of the other things that has been eating at me is the best way to
  12768. >handle "timing."  The best method will be to make the animation machine-
  12769. >independent.  If a sprite is moving across the screen at a certain speed
  12770. >on the PowerMac's, it should move at the same speed on an LC.  This may
  12771. >mean skipping frames in the animation -- or moving the sprite along 4
  12772. >pixels at a time instead of 2.
  12773. >
  12774. >   I've mulled over this one a bit, but haven't come up with anything
  12775. >that I'm particularly thrilled about.  Any suggestions?
  12776.  
  12777. Sorry about the funky From: line; this is really Al Evans (al@crucible.
  12778. powertools.com), posting from an alternate site because my newsfeed
  12779. has been hosed for the past few days.
  12780.  
  12781. Anyway: Let's take a simple case. There is an "overall" animation system
  12782. time. Each sprite has variables which represent its move interval and
  12783. its last move time. For each frame, you run through the sprite list and
  12784. update the sprites for which lastMove + moveInterval <= currentTime.
  12785.  
  12786. At this point, you have three options. First, you can set the sprite's
  12787. last move time to the current system time. The advantage of this approach
  12788. is that each frame gets drawn for each sprite. The disadvantage is that,
  12789. on entry, currentTime can easily be lastMove + (10 * moveInterval),
  12790. and the extra nine moveIntervals are lost forever. In other words, unless
  12791. the host system is fast enough that the maximum animation time is less
  12792. than the minimum move interval, the animation will slow down.
  12793.  
  12794. The second approach is to do something like
  12795.  
  12796. while ((lastMove + moveInterval) <= currentTime) {
  12797.     MoveSprite(thisSprite);
  12798.     lastMove = lastMove + moveInterval;
  12799. }
  12800.  
  12801. This keeps the sprite movement speeds the same on all systems, but leads
  12802. to skipped frames (and possible jerky animation) on slower systems. In
  12803. addition, you must provide some means of "stopping the clock" when 
  12804. you are not animating. For example, if the user holds down a menu so that
  12805. your animation loop doesn't get called for a few seconds, the sprites
  12806. will all jump to where they are supposed to be "now" if the clock has
  12807. continued running.
  12808.  
  12809. Finally, you can combine the two approaches, setting last move equal
  12810. to lastMove + moveInterval but only moving once each time through the
  12811. loop. This assumes that there will be time available at some point for
  12812. the animation to "catch up" on comparatively slow systems (for example,
  12813. a series of frames in which most sprites are standing still). With this
  12814. technique, all sprites will be where they are supposed to be -- eventually.
  12815. The problem of stopping time while the user holds down a menu (or whatever)
  12816. remains, only in this case the sprites will "run real fast" to get
  12817. where they're supposed to be when the user releases the menu.
  12818.  
  12819. I am not really satisfied with any of these approaches, but the only
  12820. better one I can think of is to measure system speed and alter the
  12821. move distances (and frame changes) of each sprite, possibly using
  12822. fixed-point numbers for fractional pixels. If anybody has a better method,
  12823. I'd like to hear it.
  12824.  
  12825. For a variety of reasons, I personally use the first method, and 
  12826. accept the inevitable slowdown on slower systems.  
  12827.  
  12828.                     --Al Evans--
  12829.  
  12830. +++++++++++++++++++++++++++
  12831.  
  12832. >From alex@metcalf.demon.co.uk (Alex Metcalf)
  12833. Date: Wed, 9 Mar 1994 18:26:03 GMT
  12834. Organization: Demon Internet
  12835.  
  12836. In article <Arsenault_C-080394123530@134.33.101.226>,
  12837. Arsenault_C@msm.cdx.mot.com (Chris Arsenault) wrote:
  12838.  
  12839. > In article <alex-060394231343@metcalf.demon.co.uk>,
  12840. > alex@metcalf.demon.co.uk (Alex Metcalf) wrote:
  12841. > >      That's all fine and well, but if your game doesn't have an event loop
  12842. > > (as most arcade games don't, since it takes too much CPU time for
  12843. > > background processing), there's nothing else to do while you're waiting for
  12844. > > the next animation interval!
  12845. > One of the things I do is to switch in and out of a main event loop.  When
  12846. > running time critical game code I stay out of the main event loop, working
  12847. > only with specific keypresses etc. When I see a special key (such as the
  12848. > space bar) I switch in and out of the main event loop where I handle events
  12849. > normally.  The nice part about this approach is I have very clean/fast
  12850. > animation without background process relinquish jitters, but I can still
  12851. > handle menus, application switching and the like.
  12852. > BTW, when you're the foreground process you can tell the system that you
  12853. > really want all the time you can by setting the WaitNextEvent sleep
  12854. > parameter to 0.
  12855.  
  12856.      Interesting.... I already have an event loop for other parts of the
  12857. game (such as loading and intro), but I hadn't considered sharing my
  12858. important game code time with other events. Worth a try!
  12859.  
  12860.      Alex
  12861.  
  12862. +++++++++++++++++++++++++++
  12863.  
  12864. >From ua025@freenet.Victoria.BC.CA (Cody Jones)
  12865. Date: Thu, 10 Mar 1994 08:58:39 GMT
  12866. Organization: The Victoria Freenet Association (VIFA), Victoria, B.C., Canada
  12867.  
  12868.  
  12869. I posted my method of handling animation-rates on different systems some
  12870. time ago.  Others have posted similar ideas and some think that it would
  12871. be wise to use Time Manager tasks to handle movement.  There is no need -
  12872. to avoid having movement be integer-multiples of the update-frequency,
  12873. simply store your velocity and positions as fixed point.  In my present
  12874. project I use 10.6 bits.  I have a routine that converts a fixed-pt.
  12875. coordinate and two lengths into a rectangle; this is used for any
  12876. memory-copying or intersection-testing.
  12877.  
  12878. Personally I think doing it this way is better than setting up a Time
  12879. Manager task for every moving object.
  12880.  
  12881. Cody Jones
  12882. Zerius Development
  12883. -- 
  12884.  
  12885. +++++++++++++++++++++++++++
  12886.  
  12887. >From s_heidri@ira.uka.de (Dietmar Heidrich)
  12888. Date: 10 Mar 1994 18:12:58 GMT
  12889. Organization: University of Karlsruhe, Comp. Sc. Dept., FRG
  12890.  
  12891. Chris Arsenault (Arsenault_C@msm.cdx.mot.com) wrote:
  12892. : In article <2lfbu7INN597@iraun1.ira.uka.de>, s_heidri@iraul1.ira.uka.de
  12893. : (Dietmar Heidrich) wrote:
  12894. : > I am no Mac programmer, but on other platforms you can switch video buffers
  12895. : > for games instead of copying everything you already have drawn.  Is there
  12896. : > no way to do that OS compliant on the Mac ?  I think CopyBits() will be too
  12897. : > slow for action games if you need to copy 640x480x8bit = 307200 bytes per
  12898. : > frame.  For 30 frames/s update rate, this yields 9 MB/s transfer rate eaten
  12899. : > up only for CopyBits().  Assuming you can transfer 16 bytes via burst (giving
  12900. : > 576000 bursts needed) in 20 clock cycles, this means 46% CPU time on a 25 MHz
  12901. : > 68040.
  12902.  
  12903. : Actually, there is a tradeoff involved. By using CopyBits we gain
  12904. : simplicity in handling numerous video configurations and application
  12905. : longevity.  What we lose is speed. We don't have a mode 13h or X. If we
  12906. : draw using Toolbox trap calls to memory on a video card, then we have to
  12907. : run over NuBus. (number of draw calls * (Trap dispatch overhead + NuBus
  12908. : overhead + actual operation) = too expensive).
  12909.  
  12910. What is mode 13h ?  I think you assume I am an Intel-Weirdo.  I AM NOT !
  12911.  
  12912. But you can design hardware-independant systems with double-buffering and
  12913. OS compliancy.  You do not have to lose speed.  And as long as the system
  12914. provides fast BitBlt() for the graphics board memory, the NuBus should not
  12915. be an obstacle.
  12916.  
  12917.  
  12918.  
  12919. Dietmar Heidrich
  12920.  
  12921. +++++++++++++++++++++++++++
  12922.  
  12923. >From dwareing@apanix.apana.org.au (David Wareing)
  12924. Date: 11 Mar 94 04:18:24 GMT
  12925. Organization: Apanix Public Access Unix, +61 8 373 5485 (5 lines)
  12926.  
  12927. mgleason@cse.unl.edu (Mike Gleason) writes:
  12928.  
  12929. >|s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) wrote:
  12930.  
  12931. >|> I am no Mac programmer, but on other platforms you can switch video buffers
  12932. >|> for games instead of copying everything you already have drawn.  Is there
  12933. >|> no way to do that OS compliant on the Mac ?  
  12934.  
  12935. >|Nope.
  12936.  
  12937. >That's pretty depressing.  The Sega Genesis and Commodore Amiga, which
  12938. >use the same damn 68000 in the Mac Plus I use, get phemomenal performance.
  12939.  
  12940. Yeah, I wonder why. Can you say "custom blitting hardware"? Decent graphic
  12941. performance is expected from both the Sega Genesis/MegaDrive and the
  12942. Amiga, as both started out life as games machines (both still are, but I
  12943. digress). The did not start their lives as multi-purpose home and business
  12944. computers. They do one job and they do it well. Want to try and run Word
  12945. or Lotus 123 on a Sega games machine? Of course not - games boxes weren't
  12946. designed to do such things. Just as the Mac Plus was not designed to play
  12947. Sonic the Hedgehog.
  12948.  
  12949. >Ever play Sonic the Hedgehog?  That should be able to be done on a mac.
  12950. >Hard to believe... 
  12951.  
  12952. *Very* hard to believe actually. Why should it be able to done on a mac?
  12953. Somehow I don't think the number one choice for buying a mac is its
  12954. ability to play Sonic. I agree that macs should eventually come standard
  12955. with some form of hardware-accelerated graphics, but lets not get carried
  12956. away and whine that you can't play Sonic on a lowly Mac Plus.
  12957.  
  12958. >I think the Amiga uses a Screen pointer, which is
  12959. >changeable by the programmer, so that to do very fast screen scrolling,
  12960. >all you need to do is set the screen pointer to something else.  It makes
  12961. >no sense to me that you have to re-copy the whole damn screen if all you
  12962. >want to do is scroll the screen downward a pixel.
  12963.  
  12964. See the comments above about the Amiga's blitting hardware. Damn it. 
  12965. Horses for courses.
  12966.  
  12967. --
  12968. David Wareing
  12969. Adelaide, South Australia
  12970. Mac Games & Multimedia Programming        dwareing@apanix.apana.org.au
  12971. - --------------------------------------------------------------------
  12972.  
  12973. +++++++++++++++++++++++++++
  12974.  
  12975. >From snozer@cats.ucsc.edu (Daniel Craig Jalkut)
  12976. Date: 14 Mar 1994 08:22:55 GMT
  12977. Organization: University of California, Santa Cruz
  12978.  
  12979.  
  12980. In <dwareing.763359504@apanix.apana.org.au> dwareing@apanix.apana.org.au (David Wareing) writes:
  12981.  
  12982.  
  12983. >Yeah, I wonder why. Can you say "custom blitting hardware"? Decent graphic
  12984. >performance is expected from both the Sega Genesis/MegaDrive and the
  12985. >Amiga, as both started out life as games machines (both still are, but I
  12986. >digress). The did not start their lives as multi-purpose home and business
  12987. >computers. They do one job and they do it well. Want to try and run Word
  12988. >or Lotus 123 on a Sega games machine? Of course not - games boxes weren't
  12989. >designed to do such things. Just as the Mac Plus was not designed to play
  12990. >Sonic the Hedgehog.
  12991.  
  12992.  
  12993. But the bottom line is that the Amiga can do everything the Mac can
  12994. do, but the converse is not true.  The advantages you point out for 
  12995. the Mac are all software(which is why i'm a mac user and no longer an 
  12996. Amigan), if the software were written as well for the Amiga(including 
  12997. the OS), then you'd have the equivalent of a Macintosh with the bonus
  12998. of excellent graphics hardware.  And the Amiga computers were sold 
  12999. for much less than macs in the past, so it's not infeasable cost-wise
  13000. that the Macs have this type of hardware for graphics. 
  13001.  
  13002. Would be nice...
  13003.  
  13004.  
  13005. +++++++++++++++++++++++++++
  13006.  
  13007. >From rba26@cas.org (Brad Andrews)
  13008. Date: Mon, 14 Mar 1994 18:08:22 GMT
  13009. Organization: Chemical Abstracts Service
  13010.  
  13011. In article dpi@darkstar.UCSC.EDU, snozer@cats.ucsc.edu (Daniel Craig Jalkut) writes:
  13012. ]
  13013. ]But the bottom line is that the Amiga can do everything the Mac can
  13014. ]do, but the converse is not true.  The advantages you point out for 
  13015.  
  13016. Hardly.  Certainly you may prefer the Amiga, and many do, but some things are
  13017. extremely difficult.  I had a lot more hastles getting an Amiga version of 
  13018. a game port running than I did on the Mac, including such things as supporting a
  13019. hard drive.
  13020.  
  13021. - -
  13022.  
  13023. Brad Andrews
  13024. brad.andrews@cas.org
  13025. All opinions are strictly mine
  13026.  
  13027.  
  13028. +++++++++++++++++++++++++++
  13029.  
  13030. >From snozer@cats.ucsc.edu (Daniel Craig Jalkut)
  13031. Date: 15 Mar 1994 16:03:41 GMT
  13032. Organization: University of California, Santa Cruz
  13033.  
  13034.  
  13035. In <1994Mar14.180822.7882@chemabs.uucp> rba26@cas.org (Brad Andrews) writes:
  13036.  
  13037. >Hardly.  Certainly you may prefer the Amiga, and many do, but some things are
  13038. >extremely difficult.  I had a lot more hastles getting an Amiga version of 
  13039. >a game port running than I did on the Mac, including such things as supporting a
  13040. >hard drive.
  13041.  
  13042.  
  13043. If I preferred Amigas, I wouldn't have said that I was a mac person.
  13044.  
  13045.  
  13046. +++++++++++++++++++++++++++
  13047.  
  13048. >From s_heidri@irau32.ira.uka.de (Dietmar Heidrich)
  13049. Date: 17 Mar 1994 13:36:48 GMT
  13050. Organization: University of Karlsruhe, FRG
  13051.  
  13052. In article <dwareing.763359504@apanix.apana.org.au>, dwareing@apanix.apana.org.au (David Wareing) writes:
  13053. |> mgleason@cse.unl.edu (Mike Gleason) writes:
  13054. |> 
  13055. |> >|s_heidri@iraul1.ira.uka.de (Dietmar Heidrich) wrote:
  13056. |> 
  13057. |> >|> I am no Mac programmer, but on other platforms you can switch video buffers
  13058. |> >|> for games instead of copying everything you already have drawn.  Is there
  13059. |> >|> no way to do that OS compliant on the Mac ?  
  13060. |> 
  13061. |> >|Nope.
  13062. |> 
  13063. |> >That's pretty depressing.  The Sega Genesis and Commodore Amiga, which
  13064. |> >use the same damn 68000 in the Mac Plus I use, get phemomenal performance.
  13065. |> 
  13066. |> Yeah, I wonder why. Can you say "custom blitting hardware"? Decent graphic
  13067. |> performance is expected from both the Sega Genesis/MegaDrive and the
  13068. |> Amiga, as both started out life as games machines (both still are, but I
  13069. |> digress). The did not start their lives as multi-purpose home and business
  13070. |> computers. They do one job and they do it well. Want to try and run Word
  13071. |> or Lotus 123 on a Sega games machine? Of course not - games boxes weren't
  13072. |> designed to do such things. Just as the Mac Plus was not designed to play
  13073. |> Sonic the Hedgehog.
  13074.  
  13075. I did not ask for special-purpose hardware, I was asking about opening and
  13076. switching two video buffers.  To me, this purely seems to be a question of
  13077. programming interface.  The MacOS does not support this (though it would be
  13078. quite simple to implement that), so the game programming idea I had is dead.
  13079.  
  13080.  
  13081.  
  13082. --
  13083. Dietmar Heidrich, Universitaet Karlsruhe, Germany
  13084.  
  13085.  
  13086. "Die Hoffnung auf den Tod ist das einzige, was mich am Leben erhaelt."
  13087.  
  13088. +++++++++++++++++++++++++++
  13089.  
  13090. >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate)
  13091. Date: Thu, 17 Mar 1994 16:15:36 GMT
  13092. Organization: DCRT, NIH, Bethesda, MD
  13093.  
  13094. In article <2m9mdgINNei4@iraun1.ira.uka.de>, s_heidri@irau32.ira.uka.de (Dietmar Heidrich) writes:
  13095. >
  13096. >I did not ask for special-purpose hardware, I was asking about opening and
  13097. >switching two video buffers.  To me, this purely seems to be a question of
  13098. >programming interface.  The MacOS does not support this (though it would be
  13099. >quite simple to implement that), so the game programming idea I had is dead.
  13100.  
  13101. But video double-buffering *is* dependant on the hardware.
  13102.  
  13103. Think about it - you need to be able to tell the video card where to look
  13104. in RAM for its frame buffer.  That sounds like hardware functionality to
  13105. me....
  13106.  
  13107. I *believe* the original Apple color video card (that they would sell you
  13108. with a Mac II) supported two switchable frame buffers in 16-color mode.
  13109. You switched between them with a Control() call to the video driver, as
  13110. I recall.  I also think that Vette! (or some other driving game?) used
  13111. this capability.
  13112.  
  13113. Unfortunately, it's not a guaranteed availability by any stretch of the
  13114. imagination, and so you can't write code depending on it.  I agree that
  13115. it would be nice to have hardware pan, though, as a documented and
  13116. required video card capability.  That's the one that's the most expensive
  13117. to do in software.  Makes the idea of a 'Xevious' clone pretty remote. :-)
  13118.  
  13119. - --------------------------------------------------------------------------
  13120. Christopher Tate            |  "I hate writing, and I hate statistics, but
  13121. MSD, Inc.                   |   most of all I hate writing about statistics.
  13122.                             |   I'd rather go to the dentist; at least there
  13123. fixer@faxcsl.dcrt.nih.gov   |   you get to spit."     -- Ed Sewell
  13124.  
  13125. +++++++++++++++++++++++++++
  13126.  
  13127. >From Pascal_Haakmat
  13128. Date: Mon, 14 Mar 94 20:09:46 +0100
  13129. Organization: (none)
  13130.  
  13131. >That's pretty depressing.  The Sega Genesis and Commodore Amiga
  13132.  DW> Horses for courses.
  13133.  
  13134. Nonetheless, it remains pretty depressing.
  13135.  
  13136.  
  13137.  
  13138.     Pascal.
  13139.  
  13140. - - Obolus 1.0.2
  13141.  * Origin:  pretty blue dreams  (2:281/202.13)
  13142.  
  13143. ---------------------------
  13144.  
  13145. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  13146. Subject: System Folder on NONstartup disk
  13147. Date: Thu, 3 Mar 94 19:51:03 PST
  13148. Organization: Peirce Software, Inc.
  13149.  
  13150. Does anyone know how to find the System Folder on a volume that isn't
  13151. the startup volume?
  13152.  
  13153.  
  13154. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  13155. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  13156. --                       -- San Jose, California USA 95117
  13157. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  13158. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  13159.  
  13160. +++++++++++++++++++++++++++
  13161.  
  13162. >From mxmora@unix.sri.com (Matt Mora)
  13163. Date: 4 Mar 1994 09:42:08 -0800
  13164. Organization: SRI International, Menlo Park, CA
  13165.  
  13166. In article <CNjbKKKX.pns11u@outpost.SF-Bay.org> peirce@outpost.SF-Bay.org 
  13167. (Michael Peirce) writes:
  13168. >Does anyone know how to find the System Folder on a volume that isn't
  13169. >the startup volume?
  13170.  
  13171. Are you talking about a volume that has a system folder that's not blessed?
  13172. If its not blessed you probably need to do a PBCatSearch.
  13173.  
  13174. If its blessed, but not the startup volume, I assume you call findfolder
  13175. with the vRefNum set to the vRefnum of the volume that you want to
  13176. look on. Being that you're Michael Peirce, you probably already
  13177. tried that it it doesn't work. In that case do scan of the disk
  13178. and look for a folder that contains the finder and system at the same level
  13179. and you have a good chance that those files parent directory is/was
  13180. a system folder.
  13181.  
  13182. Xavier
  13183.  
  13184. P.S. Are you setting up another netter's dinner?
  13185.  
  13186. -- 
  13187. ___________________________________________________________
  13188. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  13189. SRI International                       mxmora@unix.sri.com
  13190. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  13191.  
  13192. +++++++++++++++++++++++++++
  13193.  
  13194. >From Robin J. Lunge <rjl1@cornell.edu>
  13195. Date: 5 Mar 1994 03:36:41 GMT
  13196. Organization: Cornell University
  13197.  
  13198. In article <CNjbKKKX.pns11u@outpost.SF-Bay.org> Michael Peirce,
  13199. peirce@outpost.SF-Bay.org writes:
  13200. >Does anyone know how to find the System Folder on a volume that isn't
  13201. >the startup volume?
  13202.  
  13203. FindFolder ought to work on any startup disk -- whether it is the current
  13204. startup disk or not. If you are talking about a disk that is not blessed,
  13205. the only solution is to search for a folder containing a "Finder" and a
  13206. "System" (use PBCatSearch if it is available). The Finder and System
  13207. strings are script-independent.
  13208.  
  13209. +++++++++++++++++++++++++++
  13210.  
  13211. >From Ron_Hunsinger@bmug.org
  13212. Date: Sat, 05 Mar 1994 19:39:48 -0700
  13213. Organization: BMUG, Inc.
  13214.  
  13215. Michael Peirce,peirce@outpost.SF-Bay.org writes:
  13216.  
  13217. >Does anyone know how to find the System Folder on a volume that isn't
  13218. >the startup volume?
  13219.  
  13220. Its directoryID is the first longword of vcbFndrInfo.  This isn't
  13221. documented anywhere, but I don't see how they can change it, since
  13222. the ROM has to be getting the system folder from here at bootup.
  13223.  
  13224. -Ron Hunsinger
  13225.  
  13226.  
  13227.  
  13228. +++++++++++++++++++++++++++
  13229.  
  13230. >From macguru@halcyon.com. (Allan Foster)
  13231. Date: 10 Mar 1994 07:08:02 GMT
  13232. Organization: Guru Inc
  13233.  
  13234. In article <1994Mar05.193948.1193292@bmug.org>
  13235. Ron_Hunsinger@bmug.org writes:
  13236.  
  13237. > Michael Peirce,peirce@outpost.SF-Bay.org writes:
  13238. > >Does anyone know how to find the System Folder on a volume that isn't
  13239. > >the startup volume?
  13240. > Its directoryID is the first longword of vcbFndrInfo.  This isn't
  13241. > documented anywhere, but I don't see how they can change it, since
  13242. > the ROM has to be getting the system folder from here at bootup.
  13243. Except that I do not believe that the rom gets this information... 
  13244. That is all done by the boot blocks...   just my $0.02 nitpicking!
  13245.  
  13246. Allan Foster
  13247.  
  13248. - --------------------------------------------------------
  13249. I am responsible for what I say and do. -- Allan Foster --
  13250.  
  13251. ---------------------------
  13252.  
  13253. >From "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu>
  13254. Subject: Trap dispatcher overhead
  13255. Date: Tue,  1 Mar 1994 19:23:18 -0500
  13256. Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
  13257.  
  13258. Every few days, a post floats by here saying "Don't call toolbox traps
  13259. in time-critical loops; they take forever." How long is forever? I mean,
  13260. is there a nice rule like "a trap dispatch is worth 27 pointer
  13261. dereferences on a '030 CPU"?
  13262.  
  13263. What about "idiot" toolbox calls (like SetRectSize or OffsetRect, that
  13264. would be blindingly fast if compiled inline)? Is is worth #defining
  13265. macros to replace them, or do the header files take care of this? (I'd
  13266. look, but I'm not at my Mac right now.) (Think C 5.0.4 header files, if
  13267. it matters.)
  13268.  
  13269. And, most importantly :-) why doesn't Inside Macintosh tell you about
  13270. this? I originally assumed that a toolbox call was as fast as any other
  13271. function call, with maybe a couple of memory lookups and register loads
  13272. tacked on.
  13273.  
  13274. --Z
  13275.  
  13276. "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
  13277.  
  13278. +++++++++++++++++++++++++++
  13279.  
  13280. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  13281. Date: Wed, 02 Mar 1994 00:09:17 -0600
  13282. Organization: University of Illinois at Urbana-Champaign
  13283.  
  13284. In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>, "Andrew C. Plotkin"
  13285. <ap1i+@andrew.cmu.edu> wrote:
  13286.  
  13287. >Every few days, a post floats by here saying "Don't call toolbox traps
  13288. >in time-critical loops; they take forever." How long is forever? I mean,
  13289. >is there a nice rule like "a trap dispatch is worth 27 pointer
  13290. >dereferences on a '030 CPU"?
  13291.  
  13292. Examples: On the original 68000, the trap itself takes 34 clock cycles. On
  13293. the 68030, it takes 18-20 cycles. The trap dispatcher takes some amount of
  13294. time to figure out what routine to call for an individual trap word, so
  13295. you would have to add on the time it takes to go through a small search.
  13296. Then the RTE is 20 cycles on the 68000, or 18-20 cycles on the 68030. So
  13297. altogether, we're probably talking about something on the order of a
  13298. divide instruction. That's a good chunk of overhead for silly things like
  13299. SetRect, but not bad at all for other things.
  13300.  
  13301. pr
  13302. -- 
  13303. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  13304. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  13305. System manager - Cognitive Science Group, Beckman Institute, UIUC
  13306. Internet: resnick@cogsci.uiuc.edu
  13307.  
  13308. +++++++++++++++++++++++++++
  13309.  
  13310. >From ari@world.std.com (Ari I Halberstadt)
  13311. Date: Sat, 5 Mar 1994 11:11:29 GMT
  13312. Organization: The World Public Access UNIX, Brookline, MA
  13313.  
  13314. In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>,
  13315. Andrew C. Plotkin <ap1i+@andrew.cmu.edu> wrote:
  13316. >Every few days, a post floats by here saying "Don't call toolbox traps
  13317. >in time-critical loops; they take forever." How long is forever? I mean,
  13318. >is there a nice rule like "a trap dispatch is worth 27 pointer
  13319. >dereferences on a '030 CPU"?
  13320.  
  13321. If speed of execution is truly critical then you're better off not
  13322. using a Toolbox trap. For instance, context switches for threads
  13323. should be very efficient. In my Thread Library (a publicly available
  13324. implementation of nonpreemptive threads), threads are scheduled for
  13325. execution at a certain time. I wanted to reduce the time spent in
  13326. context switches, and since the scheduling loop was already pretty
  13327. minimal I substituted the use of the TickCount trap with a direct
  13328. access to the Ticks low-memory global. This resulted in nearly a 50%
  13329. decrease in the time spent in scheduling context switches. Apple's
  13330. Thread Manager is slower than Thread Library. I suspect that, at least
  13331. in part, the slowness of Apple's Thread Manager is due to its use of
  13332. traps.
  13333.  
  13334. You should, however, take great pains to use documented traps to
  13335. access the operating system. Before using the Ticks low-memory global,
  13336. I tried calling the TickCount trap only once. Instead of something
  13337. like the following:
  13338.  
  13339.   for (each thread) {
  13340.      if (TickCount() - thread->went_to_sleep >= thread->sleep_time)
  13341.         activate this thread;
  13342.   }
  13343.  
  13344. you could cache the value of TickCount, assuming the inner loop would
  13345. execute in less than 1 tick (a valid assumption for many operations).
  13346.  
  13347.   unsigned long ticks;
  13348.  
  13349.   ticks = TickCount();
  13350.   for (each thread) {
  13351.      if (ticks >= thread->time_to_wakeup) // we precalculated time_to_wakeup
  13352.        activate this thread;
  13353.   }
  13354.  
  13355. Only if this is not feasible (because the loop takes too long), or is
  13356. still too slow, should you use the Ticks low-memory global.
  13357. -- 
  13358. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  13359. "These beetles were long considered to be very rare because very few
  13360. entomologists look for beetles in the mountains, in winter, at night,
  13361. during snow storms." -- Purves W. K., et al, "Life: The Science of
  13362.  
  13363. +++++++++++++++++++++++++++
  13364.  
  13365. >From "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu>
  13366. Date: Wed,  9 Mar 1994 11:45:19 -0500
  13367. Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
  13368.  
  13369. In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>,
  13370. Andrew C. Plotkin <ap1i+@andrew.cmu.edu> wrote:
  13371. >Every few days, a post floats by here saying "Don't call toolbox traps
  13372. >in time-critical loops; they take forever." How long is forever? I mean,
  13373. >is there a nice rule like "a trap dispatch is worth 27 pointer
  13374. >dereferences on a '030 CPU"?
  13375.  
  13376. A small experiment (what, facts on the Net?) has determined that calling
  13377. the SetRect trap takes about -four times- the time of the equivalent
  13378. four assignment statements.
  13379.  
  13380. Parameters: 
  13381. '040 CPU, Centris 610
  13382. virtual memory off, 32-bit mode off
  13383. Think C 5.0.4, no optimization
  13384. A loop which just calls SetRect (or the equivalent macro) 10^n times,
  13385. same arguments each time, none of the arguments equal to zero. (Yes, I
  13386. disassembled the code and made sure it wasn't sneakily optimizing
  13387. anything away behind my back.)
  13388.  
  13389. The object size difference was a few bytes (four or six, I think), which
  13390. is unlikely to be a big deal.
  13391.  
  13392. So I put SetRect and SetPt macros into my project. And immediately it
  13393. stopped working right. Sigh. Turned out I had two calls of the form
  13394.     SetRect(&box, x, y, x+box.right-box.left, y+box.bottom-box.top);
  13395. and changing the function call to a macro changed the semantics! Heh. Be
  13396. warned.
  13397.  
  13398. Conclusion: it's worthwhile, but be careful. And in C++ you probably
  13399. want to declare an inline function rather than a macro.
  13400.  
  13401. --Z
  13402.  
  13403. "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
  13404.  
  13405. +++++++++++++++++++++++++++
  13406.  
  13407. >From macguru@halcyon.com. (Allan Foster)
  13408. Date: 10 Mar 1994 07:12:12 GMT
  13409. Organization: Guru Inc
  13410.  
  13411. In article <whTToTS00gpIFYYFsM@andrew.cmu.edu>
  13412. "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu> writes:
  13413.  
  13414. > In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>,
  13415. > Andrew C. Plotkin <ap1i+@andrew.cmu.edu> wrote:
  13416. > >Every few days, a post floats by here saying "Don't call toolbox traps
  13417. > >in time-critical loops; they take forever." How long is forever? I mean,
  13418. > >is there a nice rule like "a trap dispatch is worth 27 pointer
  13419. > >dereferences on a '030 CPU"?
  13420. > A small experiment (what, facts on the Net?) has determined that calling
  13421. > the SetRect trap takes about -four times- the time of the equivalent
  13422. > four assignment statements.
  13423.  
  13424. The trap dispatcher overhead is in the order of 120 Cycles, depending
  13425. on the machine, and which trap you are calling....  I believe that
  13426. toolbox traps take slightly longer,  (140?? cycles)
  13427.  
  13428. It is a fact that the trivial traps should rather be coded inline. 
  13429. These being SetPt, EqualPt and even the Rect calls should be inline.
  13430.  
  13431. In fact, I believe that the new MPW glue libraries actually implement
  13432. some these functions as glue rather than the trap call....  
  13433.  
  13434. For most other traps, the overhead of the dispatcher becomes
  13435. insignificant.
  13436.  
  13437. Allan Foster
  13438.  
  13439. - --------------------------------------------------------
  13440. I am responsible for what I say and do. -- Allan Foster --
  13441.  
  13442. +++++++++++++++++++++++++++
  13443.  
  13444. >From sigurasg@rhi.hi.is (Sigurdur Asgeirsson)
  13445. Date: 10 Mar 1994 14:47:33 GMT
  13446. Organization: University of Iceland
  13447.  
  13448. In <2lmh8c$5l4@nwfocus.wa.com> macguru@halcyon.com. (Allan Foster) writes:
  13449.  
  13450. >In article <whTToTS00gpIFYYFsM@andrew.cmu.edu>
  13451. >"Andrew C. Plotkin" <ap1i+@andrew.cmu.edu> writes:
  13452.  
  13453. >> In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>,
  13454. >> Andrew C. Plotkin <ap1i+@andrew.cmu.edu> wrote:
  13455. >> >Every few days, a post floats by here saying "Don't call toolbox traps
  13456. [snip]
  13457. >> 
  13458.  
  13459. >The trap dispatcher overhead is in the order of 120 Cycles, depending
  13460. >on the machine, and which trap you are calling....  I believe that
  13461. >toolbox traps take slightly longer,  (140?? cycles)
  13462.  
  13463.   When virtual memory is enabled you get some additional overhead.
  13464. Basically what happens is that the a-trap traps to supervisory level via
  13465. the VBR trap vector, then there's a shift back down to user level, and
  13466. a jump to the original lomem trap vector. I sometimes wonder if this
  13467. additional a-trap overhead is the main cause for the apparent slowdown
  13468. when VM is on.
  13469. -- 
  13470. Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
  13471. Kambasel 26            | for instance declares f as an array of unspecified 
  13472. 109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
  13473. sigurasg@rhi.hi.is     | functions that return void... I think"
  13474.  
  13475. +++++++++++++++++++++++++++
  13476.  
  13477. >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik)
  13478. Date: 10 Mar 1994 18:58:48 GMT
  13479. Organization: Case Western Reserve University, Cleveland, Ohio (USA)
  13480.  
  13481.  
  13482. In article <2lmh8c$5l4@nwfocus.wa.com> macguru@halcyon.com. (Allan Foster) writes:
  13483. > In article <whTToTS00gpIFYYFsM@andrew.cmu.edu>
  13484. > "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu> writes:
  13485. > > 
  13486. > > A small experiment (what, facts on the Net?) has determined that calling
  13487. > > the SetRect trap takes about -four times- the time of the equivalent
  13488. > > four assignment statements.
  13489. >
  13490. > The trap dispatcher overhead is in the order of 120 Cycles, depending
  13491. > on the machine, and which trap you are calling....  I believe that
  13492. > toolbox traps take slightly longer,  (140?? cycles)
  13493. >
  13494. > It is a fact that the trivial traps should rather be coded inline. 
  13495. > These being SetPt, EqualPt and even the Rect calls should be inline.
  13496.  
  13497. last night i wrote a program which takes a PEF application as input and
  13498. modifies the app so that all calls to SetRect and SetPt are made "inline".
  13499. (well, OK, i had written all of the PEF parsing stuff earlier, i just
  13500. had to modify it to scan for and modify these routines).
  13501.  
  13502. it does this by replacing the 6-instruction global linkage for the routine
  13503. with an implementation of the routine itself.  this can be done for any
  13504. routine that can be implemented in 5 (or fewer) PowerPC instructions.
  13505.  
  13506. basically, i convert:             into:
  13507.  
  13508. glink:   lwz     r12,xx(r2)            subic   r3,r3,2
  13509.          stw     r2,0x14(r1)           sthu    r5,2(r3)
  13510.          lwz     r0,0x0(r12)           sthu    r4,2(r3)
  13511.          lwz     r2,0x4(r12)           sthu    r7,2(r3)
  13512.          mtctr   r0                    sthu    r6,2(r3)
  13513.          bctr                          blr
  13514.  
  13515. i haven't tested it yet (since i don't have a PowerMac), but i see
  13516. no reason why this shouldn't work.  the only "worry" i have is that
  13517. it trashes r3 (which contains the ptr to the rect), but since SetRect
  13518. doesn't return a value and r3-r10 are volatile, i believe that this
  13519. should be OK.
  13520.  
  13521. anyway, i can't distribute this yet because of licensing issues that i
  13522. have to work out with Apple.  i wrote the code, but it's based on some
  13523. of Apple's headers -- so i need to make sure that things are OK before
  13524. i release it.  i'll post it somewhere as soon as these issues are
  13525. resolved.
  13526.  
  13527.  
  13528. -gary j kacmarcik
  13529. platypus@curie.ces.cwru.edu
  13530.  
  13531. +++++++++++++++++++++++++++
  13532.  
  13533. >From rollin@newton.apple.com (Keith Rollin)
  13534. Date: Sun, 13 Mar 1994 01:42:44 GMT
  13535. Organization: Apple Computer, Inc.
  13536.  
  13537. In article <whTToTS00gpIFYYFsM@andrew.cmu.edu>, "Andrew C. Plotkin"
  13538. <ap1i+@andrew.cmu.edu> wrote:
  13539.  
  13540. > In article <MhQxlq600gpI0WyHdn@andrew.cmu.edu>,
  13541. > Andrew C. Plotkin <ap1i+@andrew.cmu.edu> wrote:
  13542. > >Every few days, a post floats by here saying "Don't call toolbox traps
  13543. > >in time-critical loops; they take forever." How long is forever? I mean,
  13544. > >is there a nice rule like "a trap dispatch is worth 27 pointer
  13545. > >dereferences on a '030 CPU"?
  13546. > A small experiment (what, facts on the Net?) has determined that calling
  13547. > the SetRect trap takes about -four times- the time of the equivalent
  13548. > four assignment statements.
  13549. > Parameters: 
  13550. > '040 CPU, Centris 610
  13551. > virtual memory off, 32-bit mode off
  13552. > Think C 5.0.4, no optimization
  13553. > A loop which just calls SetRect (or the equivalent macro) 10^n times,
  13554. > same arguments each time, none of the arguments equal to zero. (Yes, I
  13555. > disassembled the code and made sure it wasn't sneakily optimizing
  13556. > anything away behind my back.)
  13557. > The object size difference was a few bytes (four or six, I think), which
  13558. > is unlikely to be a big deal.
  13559. > So I put SetRect and SetPt macros into my project. And immediately it
  13560. > stopped working right. Sigh. Turned out I had two calls of the form
  13561. >     SetRect(&box, x, y, x+box.right-box.left, y+box.bottom-box.top);
  13562. > and changing the function call to a macro changed the semantics! Heh. Be
  13563. > warned.
  13564. > Conclusion: it's worthwhile, but be careful. And in C++ you probably
  13565. > want to declare an inline function rather than a macro.
  13566.  
  13567.  
  13568. And after you started using the macros, was there any discernable
  13569. difference in the execution speed of your program? Was there any measurable
  13570. difference in the speed of your program?
  13571.  
  13572. I want to thank you for actually performing the experiment and seeing what
  13573. the effect of the trap dispatcher has on small functions like SetRect and
  13574. SetPt. But before a "ban calling through the trap dispatcher" campaign gets
  13575. started, I want to highlight two things:
  13576.  
  13577. 1) The overhead of the trap dispatcher is negligable for most calls. For
  13578. instance, it would be interesting to see what measurable difference there
  13579. is in calling LineTo via the trap dispatcher and calling it directly (after
  13580. a GetTrapAddress call).
  13581.  
  13582. 2) Even when there is a measurable difference, is there an _apparent_
  13583. difference? Is it worth the hassle and compatibility problems of
  13584. re-implementing system functionality inline or calling a system function
  13585. directly?
  13586.  
  13587. - --------------------------------------------------------------------------
  13588. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team
  13589. Newton
  13590.  
  13591. +++++++++++++++++++++++++++
  13592.  
  13593. >From mxmora@unix.sri.com (Matt Mora)
  13594. Date: 16 Mar 1994 16:32:25 -0800
  13595. Organization: SRI International, Menlo Park, CA
  13596.  
  13597. In article <rollin-120394174244@rollin-keith.apple.com> rollin@newton.apple.com (Keith Rollin) writes:
  13598.  
  13599. >2) Even when there is a measurable difference, is there an _apparent_
  13600. >difference? Is it worth the hassle and compatibility problems of
  13601. >re-implementing system functionality inline or calling a system function
  13602. >directly?
  13603.  
  13604. The original thread was about doing his own line drawing by writing
  13605. directly to screen. If he didn't care about that incompatibility,
  13606. then calling the trap directly is the lesser of the two evils. If your
  13607. goal is speed, calling a trap isn't going to help, no matter how
  13608. small the overhead.
  13609.  
  13610. Xavier
  13611.  
  13612. -- 
  13613. ___________________________________________________________
  13614. Matthew Xavier Mora                       Matt_Mora@sri.com
  13615. SRI International                       mxmora@unix.sri.com
  13616. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  13617.  
  13618. ---------------------------
  13619.  
  13620. >From jclark@galaxy.csc.calpoly.edu (Joseph V Clarke)
  13621. Subject: User in a menu?
  13622. Date: Tue, 08 Mar 94 19:16:35 GMT
  13623. Organization: Computer Science Department, Cal Poly SLO
  13624.  
  13625.  
  13626. An event is only generated when a menu item has been selected...
  13627. So how could I find out if the user is clicking on a menu..
  13628. (not neccessarily selecting an item, though.)  Can I patch
  13629. some kind of interrupt handler?  My application is real time
  13630. intensive and when someone holds down the menu, my app loses control
  13631. of the mac and the real time is lost (the data is crunched and when
  13632. I release the menu, it gushes out...thereby not accurately representing
  13633. the data.)
  13634.  
  13635. I would just like to clear the buffer and eliminate the data if the
  13636. user happened to be in the menu for awhile.  Suggestions?
  13637.  
  13638. Thanks for your time!
  13639.  
  13640. Joseph
  13641. -- 
  13642. Telemidi - A Mac application that allows 2 musicians to instantaneously express
  13643.            their musical ideas in real time over the phone lines.
  13644. Joseph V. Clarke ===================================== jclark@galaxy.calpoly.edu
  13645.  
  13646. +++++++++++++++++++++++++++
  13647.  
  13648. >From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
  13649. Date: Wed, 9 Mar 94 19:52:17 GMT
  13650. Organization: Network Analysis Ltd
  13651.  
  13652.  
  13653. In article <1994Mar08.191635.25383@rat.csc.calpoly.edu> (comp.sys.mac.programmer), jclark@galaxy.csc.calpoly.edu (Joseph V Clarke) writes:
  13654. > some kind of interrupt handler?  My application is real time
  13655. > intensive and when someone holds down the menu, my app loses control
  13656. > of the mac and the real time is lost (the data is crunched and when
  13657. > I release the menu, it gushes out...thereby not accurately representing
  13658. > the data.)
  13659. > I would just like to clear the buffer and eliminate the data if the
  13660. > user happened to be in the menu for awhile.  Suggestions?
  13661.  
  13662. Try using a MenuHook proc: see Inside Mac vol 1 pg 356.
  13663.  
  13664.  
  13665. Sak Wathanasin
  13666. Network Analysis Limited
  13667. 178 Wainbody Ave South, Coventry CV3 6BX, UK
  13668.  
  13669. Internet: sw@network-analysis-ltd.co.uk 
  13670. uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
  13671. Phone: (+44) 203 419996 Mobile:(+44) 850 587411  Fax: (+44) 203 690690
  13672.  
  13673. +++++++++++++++++++++++++++
  13674.  
  13675. >From paulr@syma.sussex.ac.uk (Paul Russell)
  13676. Date: Thu, 10 Mar 1994 14:41:27 GMT
  13677. Organization: University of Sussex
  13678.  
  13679. Sak Wathanasin (sw@network-analysis-ltd.co.uk) wrote:
  13680.  
  13681. : In article <1994Mar08.191635.25383@rat.csc.calpoly.edu> (comp.sys.mac.programmer), jclark@galaxy.csc.calpoly.edu (Joseph V Clarke) writes:
  13682. : > some kind of interrupt handler?  My application is real time
  13683. : > intensive and when someone holds down the menu, my app loses control
  13684. : > of the mac and the real time is lost (the data is crunched and when
  13685. : > I release the menu, it gushes out...thereby not accurately representing
  13686. : > the data.)
  13687. : > 
  13688. : > I would just like to clear the buffer and eliminate the data if the
  13689. : > user happened to be in the menu for awhile.  Suggestions?
  13690.  
  13691. : Try using a MenuHook proc: see Inside Mac vol 1 pg 356.
  13692.  
  13693. I wrote a little background tasking unit for a comms program a
  13694. few years back and I spent some time working out which traps
  13695. needed to be patched in order to get regular calls regardless
  13696. of what the user is doing.
  13697.  
  13698. It turns out that you can do this by patching two traps - GetNextEvent and
  13699. OSEventAvail (I think). GetNextEvent gets called most of the time and
  13700. OSEventAvail gets called when the mouse is down in a menu. (BTW,
  13701. WaitNextEvent calls GetNextEvent).
  13702.  
  13703. You need to make sure that your patches are in the System heap so that
  13704. they still get called when your application is switched to the background.
  13705.  
  13706. Doing this is much nicer than using VBL's, particularly when it comes
  13707. to debugging...
  13708.  
  13709. //Paul
  13710.  
  13711. -- 
  13712. |  Paul Russell               |  Internet:  P.T.Russell@sussex.ac.uk  |
  13713. |  Experimental Psychology    |  AppleLink: EP.SUSSEX                 |
  13714. |  Sussex University, Falmer  |  Telephone: +44 273 678639            |
  13715. |  Brighton BN1 9QG, England  |  Facsimile: +44 273 678433            |
  13716.  
  13717. +++++++++++++++++++++++++++
  13718.  
  13719. >From dean@genmagic.com (Dean Yu)
  13720. Date: 10 Mar 1994 21:46:46 GMT
  13721. Organization: General Magic, Inc.
  13722.  
  13723. In article <1994Mar08.191635.25383@rat.csc.calpoly.edu>
  13724. (comp.sys.mac.programmer), jclark@galaxy.csc.calpoly.edu (Joseph V Clarke)
  13725. writes:
  13726. > some kind of interrupt handler?  My application is real time
  13727. > intensive and when someone holds down the menu, my app loses control
  13728. > of the mac and the real time is lost (the data is crunched and when
  13729. > I release the menu, it gushes out...thereby not accurately representing
  13730. > the data.)
  13731. > I would just like to clear the buffer and eliminate the data if the
  13732. > user happened to be in the menu for awhile.  Suggestions?
  13733.  
  13734.   Assuming that this is an application of your own creation, and you're not
  13735. using some application framework, you know when the user started mousing
  13736. around in a menu because you called MenuSelect, and you know when the user
  13737. let go of the button because MenuSelect returns.
  13738.  
  13739. -- Dean Yu
  13740.    Negative Ethnic Role Model
  13741.    General Magic, Inc.
  13742.  
  13743. +++++++++++++++++++++++++++
  13744.  
  13745. >From KLUEV@jonathan.srcc.msu.su
  13746. Date: Sat, 12 Mar 1994 21:14:18 +0300
  13747. Organization: (none)
  13748.  
  13749. In article <1994Mar10.144127.15078@syma.sussex.ac.uk>
  13750. paulr@syma.sussex.ac.uk (Paul Russell) writes:
  13751. >Sak Wathanasin (sw@network-analysis-ltd.co.uk) wrote:
  13752. >
  13753. >: In article <1994Mar08.191635.25383@rat.csc.calpoly.edu> (comp.sys.mac.programmer), jclark@galaxy.csc.calpoly.edu (Joseph V Clarke) writes:
  13754. >: > some kind of interrupt handler?  My application is real time
  13755. >: > intensive and when someone holds down the menu, my app loses control
  13756. >: > of the mac and the real time is lost (the data is crunched and when
  13757. >: > I release the menu, it gushes out...thereby not accurately representing
  13758. >: > the data.)
  13759.  
  13760. >: Try using a MenuHook proc: see Inside Mac vol 1 pg 356.
  13761. >
  13762. >I wrote a little background tasking unit for a comms program a
  13763. >few years back and I spent some time working out which traps
  13764. >needed to be patched in order to get regular calls regardless
  13765. >of what the user is doing.
  13766. >
  13767. >It turns out that you can do this by patching two traps - GetNextEvent and
  13768. >OSEventAvail (I think). GetNextEvent gets called most of the time and
  13769. >OSEventAvail gets called when the mouse is down in a menu. (BTW,
  13770. >WaitNextEvent calls GetNextEvent).
  13771. >
  13772. >You need to make sure that your patches are in the System heap so that
  13773. >they still get called when your application is switched to the background.
  13774.  
  13775. This "system heapness" works only with VBL's, i.e. if your VBL proc
  13776. resides in sysHeap, it (proc) will not be swapped on MF switch.
  13777. This trick will not work with patching traps.
  13778. It is "near" to be impossible to make a global patch from within an
  13779. application, so you need an INIT; and if you want not an INIT but
  13780. an application - you need VBL (or other int. time)
  13781.  
  13782. Why "near"? One can install a TM or VBL task and patch the trap
  13783. for currently running application. Red banner.
  13784.  
  13785. Michael Kluev.
  13786.  
  13787. ---------------------------
  13788.  
  13789. >From jfinete@cats.ucsc.edu (Joseph Manuel Finete)
  13790. Subject: What happens if my Vertical Retrace task takes too long?
  13791. Date: 3 Mar 1994 01:33:00 GMT
  13792. Organization: University of California; Santa Cruz
  13793.  
  13794.  
  13795. My understanding of the vertical retrace manager is that you supply an
  13796. number of ticks to wait before calling the vertical retrace task, and that
  13797. your task function should update this number when it's finished.
  13798.  
  13799. My question is, if my task takes longer than one tick (1/60 th of a
  13800. second) will the number of ticks between tasks be the number of ticks
  13801. to complete the task plus the number of interval ticks? Is there any
  13802. danger in having a vertical retrace task that can't be completed in one
  13803. tick?
  13804.  
  13805. -- 
  13806. Joe Finete
  13807. jfinete@cats.ucsc.edu
  13808.  
  13809. +++++++++++++++++++++++++++
  13810.  
  13811. >From ari@world.std.com (Ari I Halberstadt)
  13812. Date: Thu, 3 Mar 1994 06:40:51 GMT
  13813. Organization: The World Public Access UNIX, Brookline, MA
  13814.  
  13815. In article <2l3eoc$k6q@darkstar.ucsc.edu>,
  13816. >My understanding of the vertical retrace manager is that you supply an
  13817. >number of ticks to wait before calling the vertical retrace task, and that
  13818. >your task function should update this number when it's finished.
  13819.  
  13820. That's true.
  13821.  
  13822. >My question is, if my task takes longer than one tick (1/60 th of a
  13823. >second) will the number of ticks between tasks be the number of ticks
  13824. >to complete the task plus the number of interval ticks? Is there any
  13825. >danger in having a vertical retrace task that can't be completed in one
  13826. >tick?
  13827.  
  13828. You definitely don't want your task to take longer than 1/60th of a
  13829. second. In fact, you want it to take substantially less than 1/60th of
  13830. a second, since there are bound to be other tasks the processor has to
  13831. handle. If your task takes too long all sorts of things will get
  13832. messed up, including cursor tracking, the Ticks low-memory global,
  13833. other VBL tasks that need to be executed every 1/60th of a second,
  13834. video updates etc. The CPU can accomplish quite a bit of processing in
  13835. a fraction of 1/60th of a second. If your task is that compute
  13836. intensive you should probably run it during null event processing.
  13837.  
  13838. For precise intervals between tasks you should investigate the
  13839. extended time manager, though even that won't work well if tasks take
  13840. too long. I've found that time manager tasks on a Mac Plus work ok up
  13841. to about 1/100th of a second, more frequent than that and the machine
  13842. gets pretty slow; this probably applies to other 68000 machines,
  13843. though faster CPUs should be able to handle smaller time slices.
  13844. -- 
  13845. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  13846. "These beetles were long considered to be very rare because very few
  13847. entomologists look for beetles in the mountains, in winter, at night,
  13848. during snow storms." -- Purves W. K., et al, "Life: The Science of
  13849.  
  13850. ---------------------------
  13851.  
  13852. >From rang@winternet.mpls.mn.us (Anton Rang)
  13853. Subject: When to StripAddress?  (was Re: Let's kill 24-bit mode!)
  13854. Date: 16 Mar 1994 01:33:27 GMT
  13855. Organization: Minnesota Angsters
  13856.  
  13857. In article <t-gaul-150394171035@infinity.i-link.com> t-gaul@i-link.com (Troy Gaul) writes:
  13858. >There are cases where you must call StripAddress for a program to function
  13859. >correctly in all 'modes'. It is possible that you haven't run across them.
  13860.  
  13861.   One which bit me last year, that I never did find documented....
  13862. It's important to call StripAddress() on any value that you pass to
  13863. InitZone().  Otherwise, something internal to the memory manager
  13864. starts to strip *some* addresses in the zone, but not others, and it
  13865. all flies apart....
  13866.  
  13867.   Other than that, hmm.  When you patch traps or change hooks (like
  13868. the routines in a GrafPort, or low-memory globals), make sure that you
  13869. call StripAddress() first.  The system might switch into 32-bit mode
  13870. and then call your routine.  (I'm sure this happens for very few
  13871. cases, but I've seen it cause problems before.)
  13872.  
  13873.   And, obviously, if you're switching modes yourself.  :-)
  13874. --
  13875. Anton Rang (rang@winternet.mpls.mn.us)
  13876.  
  13877. ---------------------------
  13878.  
  13879. >From AIKEN <INRA000@MUSICB.MCGILL.CA>
  13880. Subject: Why can't I have AEs *in* AEs?
  13881. Date: Fri, 25 Feb 1994 02:35:52 GMT
  13882. Organization: McGill University
  13883.  
  13884.     For reasons of my own (yes, I am sick and twisted) I am trying to
  13885. add an Apple Event to another Apple event as a paramater. My code
  13886. looks something like:
  13887.  
  13888. **
  13889. AppleEvent AEToSend,AEToInclude;
  13890.  
  13891.     Error=AEPutParamDesc(&AEToSend,keyDirectObject,&AEToInclude);
  13892. **
  13893.  
  13894.     the AE Manager just barfs up a -1703 err, "Wrong descriptor type".
  13895. Is this not something I'm supposed to be contemplating, or am I mis-
  13896. sing something?
  13897.  
  13898.     The funny thing is, if I do a AEPutParamPtr like:
  13899.  
  13900.     Error=AEPutParamPtr(&AEToSend,keyDirectObject,'aevt',
  13901.         &AEToInclude,sizeof(AppleEvent));
  13902.  
  13903.     Everything is hunky-dory. However, I'm concerned that this method
  13904. does not make a true duplicate of AEToInclude, which will definately
  13905. raise hell down the line. This is confusing, however, because both
  13906. methods should produce a paramater with the same keyword and descriptor
  13907. type, no?
  13908.  
  13909.     Insights *greatly* appreciated.
  13910.  
  13911.     Mark Aiken
  13912.     inra@musicb.mcgill.ca
  13913.  
  13914.  
  13915. +++++++++++++++++++++++++++
  13916.  
  13917. >From jwbaxter@olympus.net (John W. Baxter)
  13918. Date: Fri, 25 Feb 1994 00:43:56 -0800
  13919. Organization: Internet for the Olympic Peninsula
  13920.  
  13921. In article <24FEB94.23325740.0070@VM1.MCGILL.CA>, AIKEN
  13922. <INRA000@MUSICB.MCGILL.CA> wrote:
  13923.  
  13924. >     For reasons of my own (yes, I am sick and twisted) I am trying to
  13925. > add an Apple Event to another Apple event as a paramater. My code
  13926. > looks something like:
  13927. > **
  13928. > AppleEvent AEToSend,AEToInclude;
  13929. >     Error=AEPutParamDesc(&AEToSend,keyDirectObject,&AEToInclude);
  13930. > **
  13931. >     the AE Manager just barfs up a -1703 err, "Wrong descriptor type".
  13932. > Is this not something I'm supposed to be contemplating, or am I mis-
  13933. > sing something?
  13934.  
  13935. Hmmm...surprising that it's not allowed (although it's also surprising you
  13936. want to do this).  An Apple Event is almost an AERecord (but not quite).
  13937.  
  13938. >     The funny thing is, if I do a AEPutParamPtr like:
  13939. >     Error=AEPutParamPtr(&AEToSend,keyDirectObject,'aevt',
  13940. >         &AEToInclude,sizeof(AppleEvent));
  13941.  
  13942. Not a good idea.
  13943.  
  13944. >     Everything is hunky-dory. However, I'm concerned that this method
  13945. > does not make a true duplicate of AEToInclude, which will definately
  13946. > raise hell down the line. This is confusing, however, because both
  13947. > methods should produce a paramater with the same keyword and descriptor
  13948. > type, no?
  13949.  
  13950. No.  Look at the AEPutParamPtr again.  The third parameter points to an
  13951. AppleEvent.  If you go back far enough, that's just an AEDesc.  A type, and
  13952. a handle.  sizeof (AppleEvent) is 8.  So you put the 8 bytes (the type),
  13953. and the value of the address of the block's master pointer into your
  13954. AEToSend as the '----' parameter.  I strongly suspect that's not what you
  13955. want to do.
  13956.  
  13957. What MAY work is this:
  13958. 1.  Build your AEToInclude in the usual way.
  13959. 2.  Close your eyes (figuratively), and stuff 'reco' into 
  13960. AEToInclude.descriptorType  ['reco' is also known as typeAErecord, and you
  13961. should use that constant, IMHO].
  13962. 3.  Now, you should be able to add your AEToInclude to AEToSend with
  13963. AEPutParamDesc ().
  13964. 4.  On the other end, knowing what is coming in, get the parameter using
  13965. AEGetParamDesc, and stuff typeAppleEvent ('aevt') into the descriptorType
  13966. field of the AEDesc.
  13967.  
  13968. The above will probably work today.  It's asking for trouble.
  13969.  
  13970. Do you *really* want to do this???  Or...can you get by with passing an
  13971. AERecord, instead?  You can make your own AEList of attributes, if needed.
  13972. -- 
  13973. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  13974.    jwbaxter@pt.olympus.net
  13975.  
  13976. +++++++++++++++++++++++++++
  13977.  
  13978. >From lai@apple.com (Ed Lai)
  13979. Date: 25 Feb 1994 17:27:15 GMT
  13980. Organization: Apple
  13981.  
  13982. > In article <24FEB94.23325740.0070@VM1.MCGILL.CA>, AIKEN
  13983. > <INRA000@MUSICB.MCGILL.CA> wrote:
  13984. > >     For reasons of my own (yes, I am sick and twisted) I am trying to
  13985. > > add an Apple Event to another Apple event as a paramater. My code
  13986. > > looks something like:
  13987. > > 
  13988. > > **
  13989. > > AppleEvent AEToSend,AEToInclude;
  13990. > > 
  13991. > >     Error=AEPutParamDesc(&AEToSend,keyDirectObject,&AEToInclude);
  13992. > > **
  13993. > > 
  13994. > >     the AE Manager just barfs up a -1703 err, "Wrong descriptor type".
  13995. > > Is this not something I'm supposed to be contemplating, or am I mis-
  13996. > > sing something?
  13997.  
  13998. The Apple Event Manager checks to make sure you cannot stuff an Apple Event
  13999. inside another Apple Event, list or record.
  14000.  
  14001. -- 
  14002. /* Disclaimer: All statments and opinions expressed are my own */
  14003. /* Edmund K. Lai                                               */
  14004. /* Apple Computer, MS303-3A                                    */
  14005. /* 20525 Mariani Ave,                                          */
  14006. /* Cupertino, CA 95014                                         */
  14007. /* (408)974-6272                                               */
  14008. zW@h9cOi
  14009.  
  14010. +++++++++++++++++++++++++++
  14011.  
  14012. >From AIKEN <INRA000@MUSICB.MCGILL.CA>
  14013. Date: Fri, 25 Feb 1994 23:27:21 GMT
  14014. Organization: McGill University
  14015.  
  14016. In article <lai-250294092517@mac254.kip.apple.com> lai@apple.com (Ed Lai) writes:
  14017. >The Apple Event Manager checks to make sure you cannot stuff an Apple Event
  14018. >inside another Apple Event, list or record.
  14019.  
  14020.     Since this is deliberate, I assume there is a logical reason why
  14021. this is so. However, I don't see it. What gives?
  14022.  
  14023.     Mark Aiken
  14024.     inra@musicb.mcgill.ca
  14025.  
  14026.  
  14027. +++++++++++++++++++++++++++
  14028.  
  14029. >From AIKEN <INRA000@MUSICB.MCGILL.CA>
  14030. Date: Fri, 25 Feb 1994 23:48:43 GMT
  14031. Organization: McGill University
  14032.  
  14033. In article <jwbaxter-250294004357@ptpm006.olympus.net> jwbaxter@olympus.net (John W. Baxter) writes:
  14034. >In article <24FEB94.23325740.0070@VM1.MCGILL.CA>, AIKEN
  14035. ><INRA000@MUSICB.MCGILL.CA> wrote:
  14036. >
  14037. >>     For reasons of my own (yes, I am sick and twisted) I am trying to
  14038. >> add an Apple Event to another Apple event as a paramater. My code
  14039. >> looks something like:
  14040.  
  14041. [CHOP -- trying AEPutParamDesc doesn't work.]
  14042.  
  14043. >>     The funny thing is, if I do a AEPutParamPtr like:
  14044. >>
  14045. >>     Error=AEPutParamPtr(&AEToSend,keyDirectObject,'aevt',
  14046. >>         &AEToInclude,sizeof(AppleEvent));
  14047. >
  14048. >Not a good idea.
  14049. >>
  14050. >>     Everything is hunky-dory. However, I'm concerned that this method
  14051. >> does not make a true duplicate of AEToInclude, which will definately
  14052. >> raise hell down the line. This is confusing, however, because both
  14053. >> methods should produce a paramater with the same keyword and descriptor
  14054. >> type, no?
  14055. >
  14056. >No.  Look at the AEPutParamPtr again.  The third parameter points to an
  14057. >AppleEvent.  If you go back far enough, that's just an AEDesc.  A type, and
  14058. >a handle.  sizeof (AppleEvent) is 8.  So you put the 8 bytes (the type),
  14059. >and the value of the address of the block's master pointer into your
  14060. >AEToSend as the '----' parameter.  I strongly suspect that's not what you
  14061. >want to do.
  14062.  
  14063.     I know.
  14064.  
  14065.     What confuses me is this: AEPutParamDesc with the above usage
  14066. should attempt to add a copy of the supplied Apple Event (type: 'aevt')
  14067. as the direct paramater. But as a helpful Apple Person (tm) pointed
  14068. out, the AE Manager specifically watches out for this. However,
  14069. AEPutParamPtr, with the above usage, *also* tries to add a hunk of data
  14070. as the direct paramater. The descriptor type, of course, is supplied
  14071. in the arguments. AEPutParamPtr is inappropriate here because it doesn't
  14072. copy all the associated data of the AE, just its 8-byte descriptor data.
  14073. However, I find it confounding that the AE Manager would agree to add
  14074. a descriptor record of type 'aevt' from certain calls and not from
  14075. others.
  14076.  
  14077. >What MAY work is this:
  14078. >1.  Build your AEToInclude in the usual way.
  14079. >2.  Close your eyes (figuratively), and stuff 'reco' into
  14080. >AEToInclude.descriptorType  ['reco' is also known as typeAErecord, and you
  14081. >should use that constant, IMHO].
  14082. >3.  Now, you should be able to add your AEToInclude to AEToSend with
  14083. >AEPutParamDesc ().
  14084. >4.  On the other end, knowing what is coming in, get the parameter using
  14085. >AEGetParamDesc, and stuff typeAppleEvent ('aevt') into the descriptorType
  14086. >field of the AEDesc.
  14087. >
  14088. >The above will probably work today.  It's asking for trouble.
  14089.  
  14090.     I'm having trouble understanding why this is all such a bad idea.
  14091. An AppleEvent descriptor record just points to a list of other stuff,
  14092. namely attributes and parameters, right? So why *shouldn't* I be able
  14093. to add it to another AE? Why is the above likely to break in future?
  14094.  
  14095. >Do you *really* want to do this???  Or...can you get by with passing an
  14096. >AERecord, instead?  You can make your own AEList of attributes, if needed.
  14097.  
  14098.     I don't *really* have to do this. It's just that at one point, I
  14099. have data in one AE that another app will need in an AE *it* will send
  14100. in response to an AE I'm about to send it (read that slowly!). It
  14101. seemed natural to stuff a copy of the pre-fab AE that the other app
  14102. will need into the AE I'm about to send it, so that at the other end,
  14103. the app can remove the enclosed AE, twiddle the address and maybe one
  14104. or two other things, and send it off. No fuss, no muss. Oh, well.
  14105.  
  14106.     Since both apps know exactly what's supposed to be in the AEs, I
  14107. can just bundle all the data into *one* AE, that the receiving app can
  14108. rip apart to put together its own AE. But it would have been nice
  14109. to be able to send it one already ready to go.
  14110.  
  14111.     I hadn't thought of your solution, though (thanks!), but I would
  14112. love an explanation as to why it's such a bad idea before I start using
  14113. it! :-)
  14114.  
  14115.     Mark Aiken
  14116.     inra@musicb.mcgill.ca
  14117.  
  14118.  
  14119. +++++++++++++++++++++++++++
  14120.  
  14121. >From jwbaxter@olympus.net (John W. Baxter)
  14122. Date: Sat, 26 Feb 1994 00:13:49 -0800
  14123. Organization: Internet for the Olympic Peninsula
  14124.  
  14125. In article <25FEB94.20317060.0081@VM1.MCGILL.CA>, AIKEN
  14126. <INRA000@MUSICB.MCGILL.CA> wrote:
  14127.  
  14128. [a few words of quotation left out]
  14129.  
  14130. >     I hadn't thought of your solution, though (thanks!), but I would
  14131. > love an explanation as to why it's such a bad idea before I start using
  14132. > it! :-)
  14133.  
  14134. Apple specifies that once you have done your inserting of something into
  14135. any of the AE structures, the layout of the contents of the structure are
  14136. unknown to you.  They do that in part because, I suspect, they are darn
  14137. tired of working around the clever things developers have done with
  14138. knowledge of such things (like forcing a whole bunch of extra structures in
  14139. a color window).
  14140.  
  14141. So, in principal, all you know is that you toss some bytes in one end, and
  14142. the same byte values come out the other end.
  14143.  
  14144. Having said that:  You say:
  14145. > An AppleEvent descriptor record just points to a list of other stuff,
  14146. > namely attributes and parameters, right?
  14147.  
  14148. No...it only looks that way.  At each stage, the structure is flattened,
  14149. and there's only one handle involved with the AEDesc, which contains copies
  14150. of everything that has been stuffed in, whether by xxxPtr, or xxxDesc.  At
  14151. least...it's that way this week (see above).
  14152.  
  14153. -- 
  14154. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  14155.    jwbaxter@pt.olympus.net
  14156.  
  14157. +++++++++++++++++++++++++++
  14158.  
  14159. >From peter@ncrpda.curtin.edu.au (Peter N Lewis)
  14160. Date: 27 Feb 1994 12:52:03 +0800
  14161. Organization: NCRPDA, Curtin University
  14162.  
  14163. lai@apple.com (Ed Lai) writes:
  14164.  
  14165. >The Apple Event Manager checks to make sure you cannot stuff an Apple Event
  14166. >inside another Apple Event, list or record.
  14167.  
  14168. Stupid question: Why?
  14169.    Peter.
  14170. -- 
  14171. Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055
  14172.  
  14173. +++++++++++++++++++++++++++
  14174.  
  14175. >From Patrick C. Beard <beard@cs.ucdavis.edu>
  14176. Date: Mon, 28 Feb 1994 01:38:35 GMT
  14177. Organization: Dept. Of Computer Science, U.C. Davis
  14178.  
  14179. In article <24FEB94.23325740.0070@VM1.MCGILL.CA> AIKEN,
  14180. INRA000@MUSICB.MCGILL.CA writes:
  14181. >    For reasons of my own (yes, I am sick and twisted) I am trying to
  14182. >add an Apple Event to another Apple event as a paramater. My code
  14183. >looks something like:
  14184. >
  14185. >**
  14186. >AppleEvent AEToSend,AEToInclude;
  14187. >
  14188. >    Error=AEPutParamDesc(&AEToSend,keyDirectObject,&AEToInclude);
  14189. >**
  14190. >
  14191. >    the AE Manager just barfs up a -1703 err, "Wrong descriptor type".
  14192. >Is this not something I'm supposed to be contemplating, or am I mis-
  14193. >sing something?
  14194.  
  14195. I ran into the same problem. My solution? Lie to the AppleEvent manager. 
  14196. There's no reason it has to know the type of a parameter. Just make up 
  14197. one of your own.
  14198.  
  14199. Since an AppleEvent is just an AEDesc with a descriptorType and a
  14200. dataHandle,
  14201. and the type is always 'aevt', just do the following:
  14202.  
  14203.     OSErr StuffAE(AppleEvent* event, AppleEvent* nestedEvent)
  14204.     {
  14205.         OSErr result;
  14206.         
  14207.         Handle eventData = nestedEvent->dataHandle;
  14208.         HLock(eventData);
  14209.         result = AEPutParamPtr(&event, keyDirectObject, 'stuff', *eventData,
  14210.                             GetHandleSize(eventData));
  14211.         HUnlock(eventData);
  14212.         return result;
  14213.     }
  14214.  
  14215. I've used this approach, and it works.
  14216. //
  14217. // Patrick C. Beard
  14218. // Dept. of Computer Science, U. C. Davis
  14219. // beard@cs.ucdavis.edu
  14220. //
  14221.  
  14222. +++++++++++++++++++++++++++
  14223.  
  14224. >From lai@apple.com (Ed Lai)
  14225. Date: 5 Mar 1994 00:36:19 GMT
  14226. Organization: Apple
  14227.  
  14228. In article <25FEB94.19932459.0081@VM1.MCGILL.CA>, AIKEN
  14229. <INRA000@MUSICB.MCGILL.CA> wrote:
  14230.  
  14231. > In article <lai-250294092517@mac254.kip.apple.com> lai@apple.com (Ed Lai) writes:
  14232. > >The Apple Event Manager checks to make sure you cannot stuff an Apple Event
  14233. > >inside another Apple Event, list or record.
  14234. >     Since this is deliberate, I assume there is a logical reason why
  14235. > this is so. However, I don't see it. What gives?
  14236. >     Mark Aiken
  14237. >     inra@musicb.mcgill.ca
  14238.  
  14239. Well, the answer is that the Apple Event Manager is just one of the
  14240. implementations of Apple Event, and the Apple Event Transport Format
  14241. (it is in one of the tech note) specifies that there can be no
  14242. Apple Event embedded in another Apple Event.
  14243.  
  14244. Then the question is why the AETF specifies this. I guess it is
  14245. partly not to make it too complicated, and partly because an
  14246. embedded Apple Event can be misleading. Let say you create Apple
  14247. Event A and B in a machine X with some valid session id as the target
  14248. address, you embed B into A and send it off to another machine.
  14249. When it arrives at the other machine Y, the adress of Apple Event
  14250. A will be valid on arrival. However, if you pull out the Apple
  14251. Event B from Apple Event A, you get an Apple Event with an
  14252. session ID from machine X which is invalid in machine Y.
  14253.  
  14254. -- 
  14255. /* Disclaimer: All statments and opinions expressed are my own */
  14256. /* Edmund K. Lai                                               */
  14257. /* Apple Computer, MS303-3A                                    */
  14258. /* 20525 Mariani Ave,                                          */
  14259. /* Cupertino, CA 95014                                         */
  14260. /* (408)974-6272                                               */
  14261. zW@h9cOi
  14262.  
  14263. ---------------------------
  14264.  
  14265. >From dresden@albert.ma.utexas.edu (Greg Dresden)
  14266. Subject: Why use handles at all, though?
  14267. Date: 1 Mar 1994 16:43:35 -0600
  14268. Organization: University Of Texas Mathematics
  14269.  
  14270. Concerning the current debate about handles:
  14271.  
  14272. I've been reading with great interest these articles about when to lock 'em,
  14273. when to unlock 'em, and when to walk away. 
  14274.  
  14275. >From what I can pick up, it seems as if these handles are simply 
  14276. pointers to pointers. (Alas, I must have been asleep when we discussed these
  14277. in class.)
  14278.  
  14279. If this is so, why would anyone want to: (a) use handles when you could
  14280. just use pointers, and (b) use a "with" statement when you could just
  14281. type out the pointer's full name (thus saving yourself much grief.)
  14282.  
  14283. Now, I am a still-wet-behind-the-ears newbie, but I can't really
  14284. see the value of handles as a programming tool.
  14285.  
  14286. Are there any enlightened gurus out there who would like to rush to the
  14287. defense of these much-maligned objects?
  14288.  
  14289. - --------------------------------------------------
  14290. dresden@albert.ma.utexas.edu
  14291.  
  14292. +++++++++++++++++++++++++++
  14293.  
  14294. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  14295. Date: Wed, 2 Mar 1994 13:10:43 GMT
  14296. Organization: The Great Beyond
  14297.  
  14298. In article <2l0gen$k3e@albert.ma.utexas.edu> dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  14299. >Concerning the current debate about handles:
  14300. >
  14301. >I've been reading with great interest these articles about when to lock 'em,
  14302. >when to unlock 'em, and when to walk away. 
  14303. >
  14304. >From what I can pick up, it seems as if these handles are simply 
  14305. >pointers to pointers. (Alas, I must have been asleep when we discussed these
  14306. >in class.)
  14307. >
  14308. >If this is so, why would anyone want to: (a) use handles when you could
  14309. >just use pointers [...]
  14310.  
  14311. I'll try to tackle this one..
  14312.  
  14313.    Memory management on the Macintosh is different than most other
  14314. computers.  When the Mac first came out, it didn't have much memory
  14315. available for applications' use.  And Mac programs -- being graphical,
  14316. etc., tended to take up more memory than their text counterparts (even
  14317. though a lot of the Toolbox calls were in ROM.)
  14318.  
  14319.    Because of this, it was necessary to create a very efficient memory
  14320. model.
  14321.  
  14322.    Let's first look at the traditional way of allocating memory with
  14323. pointers.
  14324.  
  14325.    When you first run a program, a chunk of memory is set aside.  Then,
  14326. whenever you call NewPtr, you're taking away from that chunk.
  14327.  
  14328.    Say the memory partition is 200 kilobytes.  You go along and allocate
  14329. 100k with a pointer.  Now memory looks like this:
  14330.  
  14331. - --
  14332. |XX|  100k (allocated)
  14333. |XX|
  14334. |--|
  14335. |  |  100k (available)
  14336. |  |
  14337. - --
  14338.  
  14339.    Now you allocate 30k.  After that, you deallocate the 100k.  Now
  14340. memory looks like this:
  14341.  
  14342. - --
  14343. |  |  100k (available)
  14344. |  |
  14345. |XX|  30k (allocated)
  14346. |  |
  14347. |  |  70k (available)
  14348. - --
  14349.  
  14350.    Now say you need to allocate 110k.
  14351.  
  14352.    You can't.  You can allocate up to 100k, but no more, even though you've
  14353. technically got 170k available.
  14354.  
  14355.    Why?  Because you've fragmented the heap, as they say.  I've really
  14356. simplified things here; you can imagine just how fragmented the heap can
  14357. get before too long, especially if it's not all that large to begin with
  14358. (the ideal).
  14359.  
  14360.    Wouldn't it be great if the computer was smart enough to, say, move
  14361. that 30k down to the bottom of the heap so you could allocate the whole
  14362. 170k?
  14363.  
  14364.    Enter handles.  As if pointers weren't confusing enough, now you've
  14365. got pointers to pointers (to pointers to pointers to..)  Say we wanted
  14366. to solve our problem using pointers; we wanted to make the computer
  14367. intelligent enough to rearrange memory.  The problem is, we've got a
  14368. local variable which is a pointer to a memory address that locates your
  14369. allocation on the heap.  If the memory manager moved your allocation
  14370. on the heap, your pointer would still be pointing at the old address --
  14371. which is most likely NOT what you want.  (Unless you're one of those
  14372. "grunge" programmers.)
  14373.  
  14374.    With handles, you still maintain a pointer, but it points to a pointer
  14375. which is maintained by the memory manager, and not you.  That way, the
  14376. memory manager is free to do anything it wants with memory -- so long
  14377. as it updates that pointer it's maintaining to reflect the new location
  14378. of your memory.
  14379.  
  14380.    So long as you use YOUR pointer, you will be safe; it will always be
  14381. pointing to a pointer which points to the correct address of your memory,
  14382. even if that address changes.
  14383.  
  14384.    Other issues come up, though.  Dereferencing a pointer twice is a lot
  14385. slower than dereferencing a pointer once, so you'll probably want to
  14386. dereference that handle to get to the pointer that points straight to
  14387. the data, when you want to access that data.
  14388.  
  14389.    This can be dangerous, because the memory manager can change it at
  14390. any time (and your dereference won't reflect that change!)  When can the
  14391. memory manager move things around in the heap?  Just about anytime it
  14392. feels like it.  Many (most?) of the Toolbox functions can trigger memory
  14393. manager activity.  If you do dereference a handle, you should be careful
  14394. that memory isn't going to move; if you're uncertain, you can "lock"
  14395. the handle down, which guarantees the memory manager won't move it.
  14396. (You should unlock it when you're done so it can move it.  After all,
  14397. that's the whole point.)
  14398.  
  14399.    Does that help clear things up a bit?
  14400.  
  14401. Scott
  14402.  
  14403. - -
  14404. M. Scott Smith
  14405.  
  14406.    Macintosh developer, student, ski bum.  Eater of Cadbury's Creme Eggs.
  14407.  
  14408.  
  14409. +++++++++++++++++++++++++++
  14410.  
  14411. >From gurgle@netcom.com (Pete Gontier)
  14412. Date: Wed, 2 Mar 1994 19:51:32 GMT
  14413. Organization: cellular
  14414.  
  14415. dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  14416.  
  14417. >I've been reading with great interest these articles about when to
  14418. >lock 'em, when to unlock 'em, and when to walk away. From what I can
  14419. >pick up, it seems as if these handles are simply pointers to pointers.
  14420. >(Alas, I must have been asleep when we discussed these in class.) If
  14421. >this is so, why would anyone want to: (a) use handles when you could
  14422. >just use pointers...
  14423.  
  14424. What's misleading about many articles which discuss the pitfalls of
  14425. handle-based memory management is that they focus on the pitfalls, not
  14426. surprisingly. In fact, there is so much discussion of the pitfalls that
  14427. it must seem like handles are just a bogus design waiting to cause bugs
  14428. in otherwise innocent programs. However, handles have real positive
  14429. effects when used in low-memory siuations, because they can be moved and
  14430. recombined and shuffled in general within a heap to make the maximum
  14431. possible blocks size available to whoever needs it.
  14432.  
  14433. > ...and (b) use a "with" statement when you could just type out the
  14434. >pointer's full name (thus saving yourself much grief.)
  14435.  
  14436. Most people use WITH statements just for convenience. In some cases,
  14437. that convenience can be non-trivial. Suppose you have several nested
  14438. records. You know that a certain piece of code wants to access the
  14439. fields of one of the most deeply nested records. Suppose further that
  14440. you would like to be able to reorganize the containment structure of
  14441. this deeply nested record if and when necessary. The WITH statement,
  14442. used properly, would theoretically allow you to change less code,
  14443. thereby reducing the chance of introducing a typographical error which
  14444. coincidentally compiles without error.
  14445.  
  14446. In most cases, though, I think you're right: WITH is just expedient.
  14447.  
  14448. >Are there any enlightened gurus out there who would like to rush to the
  14449. >defense of these much-maligned objects?
  14450.  
  14451. IMO (and there are plenty who disagree with me), the era of handles is
  14452. largely over. People used to allocate handles whenever they needed a
  14453. hunk of memory out of the heap. This was necessary because the Mac had
  14454. very little memory. Now that customers expect applications to be huge,
  14455. I think you can get away with allocating pointers a lot of the time.
  14456. Large chunks of memory should probably still be in pointers. Also, don't
  14457. conclude that I think applications can be and should be huge these days.
  14458. That's obviously an unsupportable position. I am merely pointing out
  14459. that since many apps are huge, there's a little more weight on the side
  14460. of the scale for safety and robustness (pointers) than there used to be.
  14461. Also, don't use NewPtr or malloc. But that's another story altogether.
  14462. -- 
  14463.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  14464.  
  14465. +++++++++++++++++++++++++++
  14466.  
  14467. >From u9119523@sys.uea.ac.uk (Graham Cox)
  14468. Date: Thu, 3 Mar 1994 15:43:15 GMT
  14469. Organization: School of Information Systems, UEA, Norwich
  14470.  
  14471. In article <gurgleCM1z5y.4J1@netcom.com>, gurgle@netcom.com (Pete Gontier)
  14472. wrote:
  14473.  
  14474. > dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  14475. [SNIP!]
  14476.  
  14477. Just to add my two-penn'orth...
  14478.  
  14479. Once you understand WHY handles exist and HOW to use them, you hardly ever
  14480. use pointers again, and your ability as a programmer of truly stable, solid
  14481. Mac programs takes a massive leap forward. That was my experience anyway
  14482. (was it really 1986...?)
  14483.  
  14484. - ------------------------------------------------------------------------
  14485. Love & BSWK, Graham
  14486.  
  14487. -Everyone is entitled to their opinion, no matter how wrong they may be...
  14488. - ------------------------------------------------------------------------
  14489.  
  14490. +++++++++++++++++++++++++++
  14491.  
  14492. >From gurgle@netcom.com (Pete Gontier)
  14493. Date: Thu, 3 Mar 1994 20:52:39 GMT
  14494. Organization: cellular
  14495.  
  14496. gurgle@netcom.com (Pete Gontier) writes:
  14497.  
  14498. >Large chunks of memory should probably still be in pointers.
  14499.  
  14500. Yow! Here I was trying to be responsible and I let a zinger like THIS go
  14501. by. It should have read:
  14502.  
  14503. >Large chunks of memory should probably still be in handles.
  14504. -- 
  14505.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  14506.  
  14507. +++++++++++++++++++++++++++
  14508.  
  14509. >From rang@winternet.mpls.mn.us (Anton Rang)
  14510. Date: 04 Mar 1994 00:35:07 GMT
  14511. Organization: Minnesota Angsters
  14512.  
  14513. In article <gurgleCM1z5y.4J1@netcom.com> gurgle@netcom.com (Pete Gontier) writes:
  14514. >However, handles have real positive
  14515. >effects when used in low-memory siuations, because they can be moved and
  14516. >recombined and shuffled in general within a heap to make the maximum
  14517. >possible blocks size available to whoever needs it.
  14518.  
  14519.   Not just in low-memory situations, either; any time that you need to
  14520. have a memory block whose size varies dynamically, a handle is *very*
  14521. useful....
  14522. --
  14523. Anton Rang (rang@acm.org)
  14524.  
  14525. +++++++++++++++++++++++++++
  14526.  
  14527. >From Brad Koehn <koehn@macc.wisc.edu>
  14528. Date: 4 Mar 1994 01:30:22 GMT
  14529. Organization: University of Wisconsin
  14530.  
  14531. In article <gurgleCM1z5y.4J1@netcom.com> Pete Gontier, gurgle@netcom.com
  14532. writes:
  14533. >IMO (and there are plenty who disagree with me), the era of handles is
  14534. >largely over. 
  14535.  
  14536. I guess I'm one of those people.
  14537.  
  14538. >People used to allocate handles whenever they needed a
  14539. >hunk of memory out of the heap. This was necessary because the Mac had
  14540. >very little memory. 
  14541.  
  14542. That's still true. You can never have enough memory, and one pointer can
  14543. cut the RAM you have in half, no matter how much you have.
  14544.  
  14545. I'm kind of a purist, I love the Mac memory model (well, not all of it,
  14546. but within a heap anyway) and thinks it's just great. I can make great
  14547. programs that require hardly any memory to run, and they have all kinds
  14548. of cool memory management w/o requiring an MMU.
  14549.  
  14550. As long as I assume that my handles are going to move all the time,
  14551. everything's kosher. Wait, that's not true. My handles don't move all the
  14552. time, they only do during most trap calls. I don't bother to check which
  14553. ones (unless I'm in speed critical code), I just lock and unlock as
  14554. necessary. As it turns out, it's usually not all that necessary. And on
  14555. top of that, I get a nice clean heap.
  14556.  
  14557. I do wish that HLock and HUnlock weren't traps though, it bothers me that
  14558. my precious clock cycles are being stolen by the trap dispatcher (esp.
  14559. with TCL...).
  14560. _________________________________________________________________________
  14561. Brad Koehn          Data Transformations, Inc.        koehn@macc.wisc.edu
  14562.  
  14563. +++++++++++++++++++++++++++
  14564.  
  14565. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  14566. Date: 4 Mar 94 17:02:44 +1300
  14567. Organization: University of Waikato, Hamilton, New Zealand
  14568.  
  14569. In article <2l0gen$k3e@albert.ma.utexas.edu>, dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  14570. > Concerning the current debate about handles:
  14571. >
  14572. > I've been reading with great interest these articles about when to lock 'em,
  14573. > when to unlock 'em, and when to walk away.
  14574. >
  14575. > From what I can pick up, it seems as if these handles are simply
  14576. > pointers to pointers. (Alas, I must have been asleep when we discussed these
  14577. > in class.)
  14578.  
  14579. Ar, that be right.
  14580.  
  14581. > If this is so, why would anyone want to: (a) use handles when you could
  14582. > just use pointers,...
  14583.  
  14584. The thing about handles is that the memory blocks can move about in memory.
  14585. This has two consequences:
  14586.  
  14587. 1) Fragmentation is less likely when memory is running low, and
  14588. 2) You can resize the blocks.
  14589.  
  14590. Reason 1 is less important when you have megabytes to play with. However, 2
  14591. is still a very useful property: it's handy for creating all kinds of
  14592. dynamically-sized structures--arrays and the like.
  14593.  
  14594. > and (b) use a "with" statement when you could just
  14595. > type out the pointer's full name (thus saving yourself much grief.)
  14596.  
  14597. Beats me, too...
  14598.  
  14599. > Now, I am a still-wet-behind-the-ears newbie, but I can't really
  14600. > see the value of handles as a programming tool.
  14601.  
  14602. I trust I have managed to disabuse you of that notion.
  14603.  
  14604. Lawrence
  14605. a member of the society for linking things to other things.
  14606.  
  14607. +++++++++++++++++++++++++++
  14608.  
  14609. >From D.A.G.Gillies@bradford.ac.uk (DAG GILLIES)
  14610. Date: Fri, 4 Mar 1994 12:40:41 GMT
  14611. Organization: University of Bradford, UK
  14612.  
  14613. In article <gurgleCM1z5y.4J1@netcom.com> gurgle@netcom.com (Pete Gontier) writes:
  14614. >dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  14615. >
  14616. >>Are there any enlightened gurus out there who would like to rush to the
  14617. >>defense of these much-maligned objects?
  14618. >
  14619. >IMO (and there are plenty who disagree with me), the era of handles is
  14620. >largely over. People used to allocate handles whenever they needed a
  14621. >hunk of memory out of the heap. This was necessary because the Mac had
  14622. >very little memory. Now that customers expect applications to be huge,
  14623. >I think you can get away with allocating pointers a lot of the time.
  14624. >Large chunks of memory should probably still be in pointers. Also, don't
  14625. >conclude that I think applications can be and should be huge these days.
  14626. >That's obviously an unsupportable position. I am merely pointing out
  14627. >that since many apps are huge, there's a little more weight on the side
  14628. >of the scale for safety and robustness (pointers) than there used to be.
  14629. >Also, don't use NewPtr or malloc. But that's another story altogether.
  14630. >-- 
  14631.  
  14632.  
  14633. I like handles from an aesthetic point of view - they seem to me to be
  14634. a nice way of handling dynamic memory. I have a general rule of thumb for
  14635. when to use handles and when to use pointers, and it relies mainly on the
  14636. scope and lifetime of the entity for which storage is being allocated. In
  14637. general, if I am allocating an object at global scope, I will use a handle, 
  14638. to allow that object to waft around the heap and maximise available memory.
  14639. Typically, where it is being used in a function, I will lock it down (and
  14640. high) with HLockHi for the duration of that function and than free it up
  14641. again at the end. This allows me to dereference it once at the beginning of
  14642. the function for speed. However, if I am allocating an object that only
  14643. exists at local scope, and which will be destroyed when the enclosing
  14644. function returns, I will use a pointer, unless the object is needed by a
  14645. lot of functions called by the enclosing function, in which case I may well
  14646. use a Handle (and possibly lock it down as before).
  14647.  
  14648. If I am messing with resource creation (like building Finder aliases), I
  14649. will use Handles, simply because resources are Handles themselves, and
  14650. in general speed is not critical in such cases.
  14651.  
  14652. ______________________________________________________
  14653. David A. G. Gillies     (D.A.G.Gillies@bradford.ac.uk)
  14654. (c) 1994 Wittgenstein's Amazing Underwater Supermarket
  14655.  
  14656. - -------------REPLIES VIA EMAIL PLEASE---------------
  14657. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  14658.  
  14659. +++++++++++++++++++++++++++
  14660.  
  14661. >From partingt@fwi.uva.nl (Vincent Partington)
  14662. Date: 4 Mar 1994 16:08:49 GMT
  14663. Organization: FWI, University of Amsterdam
  14664.  
  14665. gurgle@netcom.com (Pete Gontier) writes:
  14666.  
  14667. >>Large chunks of memory should probably still be in pointers.
  14668. >Yow! Here I was trying to be responsible and I let a zinger like THIS go
  14669. >by. It should have read:
  14670. >>Large chunks of memory should probably still be in handles.
  14671.  
  14672. It doesn't really matter if you put large or small objects in handles.
  14673. Small objects break up the heap just as good as big objects. So if you go
  14674. with handles, go with them all the way.
  14675.  
  14676. Vincent.
  14677.  
  14678. BTW, Why isn't there a TempNewPtr call? To prevent us from cluttering the
  14679. temporary heap?
  14680. -- 
  14681. VI is better than Emacs.      | Let's     | Internet : partingt@fwi.uva.nl
  14682. MacOS is better than Windows. | start the |            vincent@tnc.nl
  14683. Unix is better than VMS.      | religious | FidoNet  : 2:281/202.15
  14684. Eiffel is better than C++.    | war!!     | NeST     : 90:500/202.15
  14685.  
  14686. +++++++++++++++++++++++++++
  14687.  
  14688. >From gurgle@netcom.com (Pete Gontier)
  14689. Date: Fri, 4 Mar 1994 20:09:41 GMT
  14690. Organization: cellular
  14691.  
  14692. rang@winternet.mpls.mn.us (Anton Rang) writes:
  14693.  
  14694. >In article <gurgleCM1z5y.4J1@netcom.com> gurgle@netcom.com (Pete Gontier) writes:
  14695. >>However, handles have real positive
  14696. >>effects when used in low-memory siuations, because they can be moved and
  14697. >>recombined and shuffled in general within a heap to make the maximum
  14698. >>possible blocks size available to whoever needs it.
  14699.  
  14700. >Not just in low-memory situations, either; any time that you need to
  14701. >have a memory block whose size varies dynamically, a handle is *very*
  14702. >useful....
  14703.  
  14704. That depends on how you define "useful", of course.
  14705.  
  14706. If you are, for example, talking about adding a couple of bytes to
  14707. a handle which takes up more than half the heap, which would be
  14708. impossible without handles, I would call that part of the low-memory
  14709. considerations.
  14710.  
  14711. The other aspects of it are about convenience and performance, not space
  14712. savings. And it's true that these also are reasons to advocate handles.
  14713. But if you can't do something at all, it doesn't matter how convenient
  14714. or fast it would have been. :-)
  14715. -- 
  14716.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  14717.  
  14718. +++++++++++++++++++++++++++
  14719.  
  14720. >From gurgle@netcom.com (Pete Gontier)
  14721. Date: Fri, 4 Mar 1994 20:18:09 GMT
  14722. Organization: cellular
  14723.  
  14724. Brad Koehn <koehn@macc.wisc.edu> writes:
  14725.  
  14726. > ...one pointer can cut the RAM you have in half, no matter how much
  14727. > you have.
  14728.  
  14729. Sure, that's true. But I'd say it's easier for the most part to keep
  14730. this in mind and avoid it rather than use handles all the time. I'm not
  14731. suggesting people allocate pointers for long-term global-state storage.
  14732. If, well into a program's lifetime, it decides it's going to allocate
  14733. a text buffer and leave it hanging around indefinitely, that buffer
  14734. shouldn't go into a pointer. For all it knows, a properly written
  14735. function has been called deep in a call hierarchy, and several bazillion
  14736. pointers may already have been allocated on the heap. Allocating another
  14737. and leaving it around could easily frag the heap and reduce the amount
  14738. of memory available to any one block.
  14739.  
  14740. >My handles don't move all the time, they only do during most trap
  14741. >calls. I don't bother to check which ones (unless I'm in speed critical
  14742. >code), I just lock and unlock as necessary.
  14743.  
  14744. I usually assume StripAddress and BlockMove are not going to move
  14745. memory, but that's about it. :-)
  14746.  
  14747. BTW, also remember to be paranoid about inter-segment calls.
  14748. -- 
  14749.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  14750.  
  14751. +++++++++++++++++++++++++++
  14752.  
  14753. >From mxmora@unix.sri.com (Matt Mora)
  14754. Date: 4 Mar 1994 09:27:52 -0800
  14755. Organization: SRI International, Menlo Park, CA
  14756.  
  14757. In article <2l62ve$97p@news.doit.wisc.edu> Brad Koehn <koehn@macc.wisc.edu> writes:
  14758. >In article <gurgleCM1z5y.4J1@netcom.com> Pete Gontier, gurgle@netcom.com
  14759. >writes:
  14760. >>IMO (and there are plenty who disagree with me), the era of handles is
  14761. >>largely over. 
  14762. >
  14763. >I guess I'm one of those people.
  14764.  
  14765. Me too. (if your talking about wanting to keep Handles) I think Handles
  14766. are cool but always wished they did more. Why couldn't handles, when being
  14767. moved to make room, jump over locked blocks? Handles can become pretty useless
  14768. if there are a few locked blocks in memory. I think handles should have been
  14769. more automagic. The memeory manager should take care of the details for me.
  14770.  
  14771. For example. Why couldn't we call one function to tell the memory
  14772. manager that we are about to use the data thats in the handle. ie:
  14773.  
  14774. HUsingHandle(h);
  14775. <do what ever I want with the handle because its is now in a safe state>
  14776. HNotUsingHandle(h);
  14777.  
  14778. After marking the handle as not in use, the system is now free to do anything
  14779. it wants with the handle. That includes paging it to disk, moving it around, 
  14780. jumping over locked memory islands, or even compressing it.
  14781.  
  14782. Certain functions would call these functions internally like DrawPicture.
  14783. So you know that when you call drawpicture the system would do anything
  14784. that it needs to bring the handle to a safe state and then use the data.
  14785.  
  14786. With the PowerPC machines, things like this are possible.
  14787.  
  14788. Xavier
  14789.  
  14790.  
  14791. -- 
  14792. ___________________________________________________________
  14793. Matthew Xavier Mora                    Matt_Mora@qm.sri.com
  14794. SRI International                       mxmora@unix.sri.com
  14795. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  14796.  
  14797. +++++++++++++++++++++++++++
  14798.  
  14799. >From j-norstad@nwu.edu (John Norstad)
  14800. Date: Fri, 04 Mar 1994 18:41:08 -0600
  14801. Organization: Northwestern University
  14802.  
  14803. In article <2l0gen$k3e@albert.ma.utexas.edu>, dresden@albert.ma.utexas.edu
  14804. (Greg Dresden) wrote:
  14805.  
  14806. > Are there any enlightened gurus out there who would like to rush to the
  14807. > defense of these much-maligned objects?
  14808.  
  14809. Yes, I will.
  14810.  
  14811. Relocatable memory blocks are incredibly useful for storying varying
  14812. amounts of data when you don't know in advance how much memory you are
  14813. going to need, and when the memory needs grow and shrink during the
  14814. lifetime of the block.
  14815.  
  14816. The Mac memory manager can easily make a relocatable block larger by
  14817. moving it or by moving other relocatable blocks out of the way. This is
  14818. not possible in fixed block systems.
  14819.  
  14820. This is incredibly useful. All of my Mac programs make extensive use of
  14821. this feature of the Mac memory manager, and would be very significantly
  14822. more difficult to write on a system without relocatable blocks.
  14823.  
  14824. For example, in my NewsWatcher program, I use this in dozens of places.
  14825. It's an extraordinarily useful technique. I have grow so accustomed to
  14826. having it that I find it difficult to live without it when I have to deal
  14827. with programming on other systems. Programing without relocatable and
  14828. growable blocks is like returning to the pre-Mac stone ages for me.
  14829.  
  14830. SetHandleSize(h, GetHandleSize(h) + n) is one of my favorite lines of C on
  14831. the Mac, and is one of the many reasons I find programming the Mac to be
  14832. much more fun and pleasant than programming other kinds of computers.
  14833.  
  14834. Yes, you do have to be very careful about dangling pointers. It's the
  14835. price paid for the flexibility.
  14836.  
  14837. I have also used a system (Control Data's NOS/VE) where each process could
  14838. use a very large number of very large separate virtual address spaces. On
  14839. those systems, you put varying size objects in their own address space.
  14840.  
  14841. -- 
  14842. John Norstad
  14843. Academic Computing and Network Services
  14844. Northwestern University
  14845. j-norstad@nwu.edu
  14846.  
  14847. +++++++++++++++++++++++++++
  14848.  
  14849. >From ari@world.std.com (Ari I Halberstadt)
  14850. Date: Sat, 5 Mar 1994 11:18:56 GMT
  14851. Organization: The World Public Access UNIX, Brookline, MA
  14852.  
  14853. In article <2l7r2o$t2f@unix.sri.com>, Matt Mora <mxmora@unix.sri.com> wrote:
  14854. >Me too. (if your talking about wanting to keep Handles) I think Handles
  14855. >are cool but always wished they did more. Why couldn't handles, when being
  14856.  
  14857. If we're on the subject of wish lists...
  14858.  
  14859. How about a language with a decent garbage collection coroutine? Since
  14860. the garbage collector would track all memory references, we could let
  14861. the garbage collector automagically compact the heap for us. Handles
  14862. would be obsolete and most memory errors would be obsolete (e.g.,
  14863. using disposed memory, forgetting to dispose of memory, even address
  14864. and bus errors would be very rare with such a language). To top it all
  14865. off, our programs would be a heck of a lot simpler and easier to write
  14866. and maintain. I wouldn't worry too much about speed. Algorithms are
  14867. always getting better, and we can always just throw another CPU at the
  14868. problem (i.e., parallelize the garbage collection).
  14869. -- 
  14870. Ari Halberstadt    ari@world.std.com     #include <std/disclaimer.h>
  14871. "These beetles were long considered to be very rare because very few
  14872. entomologists look for beetles in the mountains, in winter, at night,
  14873. during snow storms." -- Purves W. K., et al, "Life: The Science of
  14874.  
  14875. +++++++++++++++++++++++++++
  14876.  
  14877. >From gurgle@netcom.com (Pete Gontier)
  14878. Date: Sat, 5 Mar 1994 22:28:41 GMT
  14879. Organization: cellular
  14880.  
  14881. partingt@fwi.uva.nl (Vincent Partington) writes:
  14882.  
  14883. >gurgle@netcom.com (Pete Gontier) writes:
  14884.  
  14885. >>>Large chunks of memory should probably still be in pointers.
  14886. >>Yow! Here I was trying to be responsible and I let a zinger like THIS go
  14887. >>by. It should have read:
  14888. >>>Large chunks of memory should probably still be in handles.
  14889.  
  14890. >It doesn't really matter if you put large or small objects in handles.
  14891. >Small objects break up the heap just as good as big objects. So if you go
  14892. >with handles, go with them all the way.
  14893.  
  14894. I don't think this is valid. If you know what you are doing, it does
  14895. in fact make sense to put small objects in pointers and large objects
  14896. in handles in many contexts. Size is not the only consideration, as I
  14897. posted elsewhere; however, large objects should probably go in handles
  14898. regardless of other considerations; I believe that would have been more
  14899. evident if I had quoted more of the original message.
  14900. -- 
  14901.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  14902.  
  14903. +++++++++++++++++++++++++++
  14904.  
  14905. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  14906. Date: 7 Mar 94 14:57:51 +1300
  14907. Organization: University of Waikato, Hamilton, New Zealand
  14908.  
  14909. In article <u9119523-030394154315@case6.sys.uea.ac.uk>, u9119523@sys.uea.ac.uk (Graham Cox) writes:
  14910. >
  14911. > Once you understand WHY handles exist and HOW to use them, you hardly ever
  14912. > use pointers again, and your ability as a programmer of truly stable, solid
  14913. > Mac programs takes a massive leap forward. That was my experience anyway
  14914. > (was it really 1986...?)
  14915.  
  14916. My Mac experience dates from about the same time (I started getting seriously
  14917. into Mac programming about 86/87), and I would say "No way!".
  14918.  
  14919. I wrote some code which created a sorted tree structure once. Initially each
  14920. block was relocatable. Every now and then, the program would print garbage for
  14921. the contents of a tree node. Obviously a block was moving unexpectedly from
  14922. under me.
  14923.  
  14924. Rather than try to track down the exact place where I was forgetting to lock
  14925. the block, I changed all the relocatable blocks for the tree nodes to
  14926. nonrelocatable ones. This is how a conventional tree or linked list structure
  14927. is built in the textbooks, anyway. The program worked fine after that.
  14928.  
  14929. Moral: use nonrelocatable blocks for large numbers of identically-sized blocks.
  14930. I don't think that creating large numbers of handles is a good idea (unless
  14931. you manage the master pointers quite carefully). If you're doing a lot of
  14932. allocating and deallocating of blocks of a particular size, you could create
  14933. a lookaside list to speed things up. I tend to use handles where the system
  14934. encourages (or forces) me to, and where I need resizable structures.
  14935.  
  14936. And, yes, I do make frequent use of resizable structures.
  14937.  
  14938. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  14939. Info & Tech Services Division              fax: +64-7-838-4066
  14940. University of Waikato            electric mail: ldo@waikato.ac.nz
  14941. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  14942.  
  14943. +++++++++++++++++++++++++++
  14944.  
  14945. >From bcollett@hamilton.edu (Brian Collett)
  14946. Date: 8 Mar 1994 17:13:07 GMT
  14947. Organization: Hamilton College
  14948.  
  14949. In article <1994Mar7.145751.26071@waikato.ac.nz>, ldo@waikato.ac.nz
  14950. (Lawrence D'Oliveiro, Waikato University) wrote:
  14951. > Moral: use nonrelocatable blocks for large numbers of identically-sized blocks.
  14952. > I don't think that creating large numbers of handles is a good idea (unless
  14953. > you manage the master pointers quite carefully). If you're doing a lot of
  14954. > allocating and deallocating of blocks of a particular size, you could create
  14955. > a lookaside list to speed things up. I tend to use handles where the system
  14956. > encourages (or forces) me to, and where I need resizable structures.
  14957.  
  14958. If you are manipulating large numbers of identical blocks then it is highly
  14959. advantageous to pre-allocate a large chunk of them and then manage them
  14960. yourself (I use a simple linked list of free blocks). Identical size blocks
  14961. have no fragmentation problems and you can write a MUCH faster memory
  14962. manager for them. I have cut the memory manager overhead in a program that
  14963. manipulates many dynamic blocks from  >50% of the total execution time to
  14964. <10% by this trick.
  14965.  
  14966. Brian Collett, Physics Dept., Hamilton College, Clinton, NY 13323
  14967.  
  14968. +++++++++++++++++++++++++++
  14969.  
  14970. >From Brad Miller  <miller@cs.rochester.edu>
  14971. Date: Tue, 8 Mar 1994 17:16:27 -0500
  14972. Organization: University of Rochester Computer Science Dept
  14973.  
  14974. >>>>> "Ari" == Ari I Halberstadt <ari@world.std.com> writes:
  14975.  
  14976.     Ari> In article <2l7r2o$t2f@unix.sri.com>, Matt Mora <mxmora@unix.sri.com> wrote:
  14977.     >> Me too. (if your talking about wanting to keep Handles) I think Handles are cool but always wished they did
  14978.     >> more. Why couldn't handles, when being
  14979.  
  14980.     Ari> If we're on the subject of wish lists...
  14981.  
  14982.     Ari> How about a language with a decent garbage collection coroutine? Since the garbage collector would track all
  14983.     Ari> memory references, we could let the garbage collector automagically compact the heap for us. Handles would be
  14984.     Ari> obsolete and most memory errors would be obsolete (e.g., using disposed memory, forgetting to dispose of
  14985.     Ari> memory, even address and bus errors would be very rare with such a language). To top it all off, our programs
  14986.     Ari> would be a heck of a lot simpler and easier to write and maintain. I wouldn't worry too much about
  14987.     Ari> speed. Algorithms are always getting better, and we can always just throw another CPU at the problem (i.e.,
  14988.     Ari> parallelize the garbage collection).  -- Ari Halberstadt ari@world.std.com #include <std/disclaimer.h> "These
  14989.     Ari> beetles were long considered to be very rare because very few entomologists look for beetles in the mountains,
  14990.     Ari> in winter, at night, during snow storms." -- Purves W. K., et al, "Life: The Science of
  14991.  
  14992. It already exists, it's called "Lisp". The apple implementation, "Macintosh
  14993. Common Lisp" is quite good too.
  14994.  
  14995. Handles shouldn't be needed with any "real" VM. Arguably, the same is true for garbage, if you have a big enough heap.
  14996.  
  14997.  
  14998. +++++++++++++++++++++++++++
  14999.  
  15000. >From tblanch@lookout.ecte.uswc.uswest.com (Todd Blanchard)
  15001. Date: Mon, 7 Mar 1994 23:44:48 GMT
  15002. Organization: US WEST Information Technologies
  15003.  
  15004. Graham Cox (u9119523@sys.uea.ac.uk) wrote:
  15005. : In article <gurgleCM1z5y.4J1@netcom.com>, gurgle@netcom.com (Pete Gontier)
  15006. : wrote:
  15007.  
  15008. : > dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  15009. : > 
  15010. : [SNIP!]
  15011.  
  15012. : Just to add my two-penn'orth...
  15013.  
  15014. : Once you understand WHY handles exist and HOW to use them, you hardly ever
  15015. : use pointers again, and your ability as a programmer of truly stable, solid
  15016. : Mac programs takes a massive leap forward. That was my experience anyway
  15017. : (was it really 1986...?)
  15018.  
  15019. Perhaps, but I'm rather used to doing things like:
  15020.  
  15021.     myObject = new Object();
  15022.     myObject->Message();
  15023.     delete myObject;
  15024.  
  15025. This is the very stuff of C++ and I really like it.  Handles are OK for
  15026. buffers and such but they don't make C++ very nice to implement.  A good
  15027. VM system sort of negates the value of the things.
  15028.  
  15029. JMO
  15030. Todd Blanchard
  15031.  
  15032.  
  15033. +++++++++++++++++++++++++++
  15034.  
  15035. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  15036. Date: Fri, 11 Mar 94 11:23:45 PST
  15037. Organization: Peirce Software, Inc.
  15038.  
  15039.  
  15040. In article <j-norstad-040394184108@aragorn12.acns.nwu.edu> (comp.sys.mac.programmer), j-norstad@nwu.edu (John Norstad) writes:
  15041. > In article <2l0gen$k3e@albert.ma.utexas.edu>, dresden@albert.ma.utexas.edu
  15042. > (Greg Dresden) wrote:
  15043. > > Are there any enlightened gurus out there who would like to rush to the
  15044. > > defense of these much-maligned objects?
  15045. > Yes, I will.
  15046. > Relocatable memory blocks are incredibly useful for storying varying
  15047. > amounts of data when you don't know in advance how much memory you are
  15048. > going to need, and when the memory needs grow and shrink during the
  15049. > lifetime of the block.
  15050. > The Mac memory manager can easily make a relocatable block larger by
  15051. > moving it or by moving other relocatable blocks out of the way. This is
  15052. > not possible in fixed block systems.
  15053. > This is incredibly useful. All of my Mac programs make extensive use of
  15054. > this feature of the Mac memory manager, and would be very significantly
  15055. > more difficult to write on a system without relocatable blocks.
  15056.  
  15057. I agree with John.  Handles are really useful mainly because they
  15058. are resizable.  You simply can't do this with simple pointers.
  15059.  
  15060. I don't really understand why some people want to banish handles and
  15061. regress to a pointer only memory model.  Yuck.
  15062.  
  15063.  
  15064. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  15065. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  15066. --                       -- San Jose, California USA 95117
  15067. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  15068. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  15069.  
  15070. +++++++++++++++++++++++++++
  15071.  
  15072. >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik)
  15073. Date: 11 Mar 1994 23:13:44 GMT
  15074. Organization: Case Western Reserve University, Cleveland, Ohio (USA)
  15075.  
  15076. In article <CNjbKKKX.qc1a0h@outpost.SF-Bay.org> peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  15077. >
  15078. > In article <j-norstad-040394184108@aragorn12.acns.nwu.edu> (comp.sys.mac.programmer), j-norstad@nwu.edu (John Norstad) writes:
  15079. > > 
  15080. > > Relocatable memory blocks are incredibly useful for storying varying
  15081. > > amounts of data when you don't know in advance how much memory you are
  15082. > > going to need, and when the memory needs grow and shrink during the
  15083. > > lifetime of the block.
  15084. > > 
  15085. > > The Mac memory manager can easily make a relocatable block larger by
  15086. > > moving it or by moving other relocatable blocks out of the way. This is
  15087. > > not possible in fixed block systems.
  15088. >
  15089. > I agree with John.  Handles are really useful mainly because they
  15090. > are resizable.  You simply can't do this with simple pointers.
  15091.  
  15092. while i agree that handles are useful.  pointers _can_ be resizable.
  15093.  
  15094. for example, the following routine:
  15095.  
  15096. int ReallocPtr(Ptr *p,Size newSize)  {
  15097.    Ptr new_p;
  15098.  
  15099.    // try to resize the pointer
  15100.    SetPtrSize(p,newSize);
  15101.    if(MemError() == noErr)
  15102.       return(0);
  15103.  
  15104.    // couldn't simply resize, re-allocate the ptr
  15105.    new_p = NewPtrClear(newSize);
  15106.    if(MemError() != noErr)
  15107.       return(1);
  15108.  
  15109.    // copy the data from the old area to the new area
  15110.    BlockMove(*p,new_p,GetPtrSize(*p));
  15111.  
  15112.    // trash the old ptr
  15113.    DisposePtr(*p);
  15114.  
  15115.    *p = new_p;
  15116.    return(0);
  15117.    }
  15118.  
  15119. this does basically the same thing that ResizeHandle() does with handles
  15120. or that realloc() does for pointers in ANSI C.
  15121.  
  15122. anyway, handles are more convenient than using the above code, but
  15123. i just wanted to show that Ptr's _can_ be resized.
  15124.  
  15125.  
  15126. -gary j kacmarcik
  15127. platypus@curie.ces.cwru.edu
  15128.  
  15129. +++++++++++++++++++++++++++
  15130.  
  15131. >From u9119523@sys.uea.ac.uk (Graham Cox)
  15132. Date: Fri, 11 Mar 1994 12:37:54 GMT
  15133. Organization: School of Information Systems, UEA, Norwich
  15134.  
  15135. In article <CMBJAo.H8t@da_vinci.it.uswc.uswest.com>,
  15136. tblanch@lookout.ecte.uswc.uswest.com (Todd Blanchard) wrote:
  15137.  
  15138. > Graham Cox (u9119523@sys.uea.ac.uk) wrote:
  15139. > : In article <gurgleCM1z5y.4J1@netcom.com>, gurgle@netcom.com (Pete Gontier)
  15140. > : wrote:
  15141. > : > dresden@albert.ma.utexas.edu (Greg Dresden) writes:
  15142. > : > 
  15143. > : [SNIP!]
  15144. > : Just to add my two-penn'orth...
  15145. > : Once you understand WHY handles exist and HOW to use them, you hardly ever
  15146. > : use pointers again, and your ability as a programmer of truly stable, solid
  15147. > : Mac programs takes a massive leap forward. That was my experience anyway
  15148. > : (was it really 1986...?)
  15149. > Perhaps, but I'm rather used to doing things like:
  15150. >     myObject = new Object();
  15151. >     myObject->Message();
  15152. >     delete myObject;
  15153.  
  15154. Yeah, me too!
  15155.  
  15156. > This is the very stuff of C++ and I really like it.  Handles are OK for
  15157. > buffers and such but they don't make C++ very nice to implement.  A good
  15158. > VM system sort of negates the value of the things.
  15159. > JMO
  15160. > Todd Blanchard
  15161.  
  15162. I don't see why. A handle is a mechanism for implemeinting efficient memory
  15163. usage. In the original (non C++) implementation of the THINK class library
  15164. objects WERE handles. Did the programmer care? No- the indirection was
  15165. hidden from the programmer. Upshot- easy to write syntax PLUS efficient
  15166. memory management. In C++ I believe that objects are pointers. What
  15167. difference does it make to the programmer?- none. The syntax is identical.
  15168. The code is portable. However the fragmentation problem is still there, and
  15169. presumably C++ apps either suffer as a result or have their own memory
  15170. management code.
  15171.  
  15172. Personally, though I'm very much sold on OOP, I still like and appreciate
  15173. handles, and would prefer that C++ implemented object as handles.
  15174.  
  15175. - ------------------------------------------------------------------------
  15176. Love & BSWK, Graham
  15177.  
  15178. -Everyone is entitled to their opinion, no matter how wrong they may be...
  15179. - ------------------------------------------------------------------------
  15180.  
  15181. +++++++++++++++++++++++++++
  15182.  
  15183. >From rang@winternet.mpls.mn.us (Anton Rang)
  15184. Date: 12 Mar 1994 04:48:12 GMT
  15185. Organization: Minnesota Angsters
  15186.  
  15187. In article <PLATYPUS.94Mar11181344@cirrus.som.cwru.edu> platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
  15188. >while i agree that handles are useful.  pointers _can_ be resizable.
  15189. > [ ... example of re-allocating pointers, pass in ptr, pass out ptr ... ]
  15190.  
  15191.   The problem with re-allocating a pointer using such a routine is
  15192. that it doesn't update any *other* pointers to the same memory block.
  15193. So if you have a data structure whose size needs to change, you need
  15194. to track every pointer to it.  At that point, you're just re-inventing
  15195. handles.
  15196. --
  15197. Anton Rang (rang@winternet.mpls.mn.us)
  15198.  
  15199. +++++++++++++++++++++++++++
  15200.  
  15201. >From gurgle@netcom.com (Pete Gontier)
  15202. Date: Sat, 12 Mar 1994 06:03:23 GMT
  15203. Organization: cellular
  15204.  
  15205. platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
  15206.  
  15207. >while i agree that handles are useful.  pointers _can_ be resizable.
  15208.  
  15209. >for example, the following routine:
  15210.  
  15211. >int ReallocPtr(Ptr *p,Size newSize)  {
  15212. >   ...
  15213. >   return(0);
  15214. >   }
  15215.  
  15216. If this is an actual routine you are using, allow me to make a
  15217. suggestion. Since it always returns 0, you might care to change it so it
  15218. returns the resized pointer.
  15219.  
  15220.     void * ReallocPtr (void *p, Size newSize);
  15221.  
  15222. I am using something like this and it works dandy. What returning the
  15223. resized pointer buys you is less nasty casting to get the parameter right.
  15224. With the original version, you might have to do something like this:
  15225.  
  15226.     void foo (int *bar)
  15227.     {
  15228.         int x = ReallocPtr ((Ptr *) &bar, sizeof (*bar));
  15229.     }
  15230.  
  15231. I know I would get this cast wrong more often than I care to admit.
  15232. With the newer declaration, you could write the same function like this:
  15233.  
  15234.     void foo (int *bar)
  15235.     {
  15236.         bar = ReallocPtr (bar,sizeof (*bar));
  15237.     }
  15238. -- 
  15239.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  15240.  
  15241. +++++++++++++++++++++++++++
  15242.  
  15243. >From john_werner@taligent.com (John Werner)
  15244. Date: Sat, 12 Mar 1994 07:18:31 GMT
  15245. Organization: Taligent, Inc.
  15246.  
  15247. In article <u9119523-110394123755@graphics9.sys.uea.ac.uk>,
  15248. u9119523@sys.uea.ac.uk (Graham Cox) wrote:
  15249.  
  15250. > In the original (non C++) implementation of the THINK class library
  15251. > objects WERE handles.
  15252.  
  15253. They still are, unfortunately.
  15254.  
  15255. > Did the programmer care?
  15256.  
  15257. Yes.  You have to be very careful to lock TCL objects if you're going to
  15258. pass around pointers to any of their fields.  References make this even
  15259. worse, since it's not clear from looking at a piece of code whether
  15260. references are involved.
  15261.  
  15262. Code as innocuous looking as this:
  15263.  
  15264.   class foo : public TObject {
  15265.     Complex a, b;
  15266.     Complex bar();
  15267.   };
  15268.   
  15269.   Complex foo::bar() { return a + b; }
  15270.  
  15271. can screw you up if operator+ uses references and foo::bar is in an
  15272. unloaded segment.
  15273.  
  15274. It could be argued that this is a compiler bug.  The C++ standard (such as
  15275. it is) says that references and pointers are supposed to refer or point to
  15276. the original object for as long as it exists.  In this case they don't. 
  15277.   
  15278. > Upshot- easy to write syntax PLUS efficient memory management.
  15279.  
  15280. It's quite possible to write an efficient pointer-based memory manager. 
  15281. Heaps may take up a bit more space, but they're a lot faster, since you can
  15282. don't have to move blocks around all the time.  With decent virtual memory,
  15283. large resizable blocks like editing buffers aren't a big issue, because you
  15284. can use memory-mapped files (ala Unix's mmap) for them.
  15285.  
  15286. -- 
  15287. John Werner                          john_werner@taligent.com
  15288. Taligent, Inc.
  15289.  
  15290. +++++++++++++++++++++++++++
  15291.  
  15292. >From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
  15293. Date: Sat, 12 Mar 94 09:25:50 GMT
  15294. Organization: Network Analysis Ltd
  15295.  
  15296.  
  15297. In article <RANG.94Mar11224814@icicle.winternet.mpls.mn.us> (comp.sys.mac.programmer), rang@winternet.mpls.mn.us (Anton Rang) writes:
  15298. > In article <PLATYPUS.94Mar11181344@cirrus.som.cwru.edu> platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
  15299. > >while i agree that handles are useful.  pointers _can_ be resizable.
  15300. > > [ ... example of re-allocating pointers, pass in ptr, pass out ptr ... ]
  15301. >   The problem with re-allocating a pointer using such a routine is
  15302. > that it doesn't update any *other* pointers to the same memory block.
  15303. > So if you have a data structure whose size needs to change, you need
  15304. > to track every pointer to it.  At that point, you're just re-inventing
  15305. > handles.
  15306. > --
  15307. > Anton Rang (rang@winternet.mpls.mn.us)
  15308.  
  15309. And, of course, it's considered an "advanced C++ idiom"* these days to
  15310. use ptrs to objects that may not actually be there. Variously known as
  15311. smart pointers, envelopes &c (yes, I know they are not exactly the
  15312. same), they can used to implement persistent objects, smart memory
  15313. allocation and deallocation, bounds checking on access and so on. Mac
  15314. OS handles are a special case of these.
  15315.  
  15316. Anyone remember Iliffe's "Basic machine"? (That's "basic" as in
  15317. "fundamental", not "BASIC" as in "programming language".) Mostly a
  15318. paper design, but some of the ideas were implemented in the Burroughs
  15319. Algol engines. And capability-based systems? The "descriptor
  15320. registers" in ICL 2900/MU5 architectures? (Oh dear! showing my age :-)
  15321.  
  15322. The more things change,...
  15323.  
  15324.  
  15325. * Coplien: Advanced C++ Programing Styles and Idioms
  15326.   Alger: "C++ for gurus" in latest issue of Frameworks
  15327.  
  15328.  
  15329. Sak Wathanasin
  15330. Network Analysis Limited
  15331. 178 Wainbody Ave South, Coventry CV3 6BX, UK
  15332.  
  15333. Internet: sw@network-analysis-ltd.co.uk 
  15334. uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
  15335. Phone: (+44) 203 419996 Mobile:(+44) 850 587411  Fax: (+44) 203 690690
  15336.  
  15337. +++++++++++++++++++++++++++
  15338.  
  15339. >From peirce@outpost.SF-Bay.org (Michael Peirce)
  15340. Date: Sat, 12 Mar 94 09:31:56 PST
  15341. Organization: Peirce Software, Inc.
  15342.  
  15343. platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
  15344.  
  15345. >while i agree that handles are useful.  pointers _can_ be resizable.
  15346.  
  15347. >for example, the following routine:
  15348.  
  15349. >int ReallocPtr(Ptr *p,Size newSize)  {
  15350. >   ...
  15351. >   return(0);
  15352. >   }
  15353.  
  15354. Two problems:
  15355.  
  15356. (1) This works OK if you have basically unlimited memory
  15357. available to you.  If you don't, you can easily run into a
  15358. situation where you have a memory block of size N and free memory
  15359. of size N and you want to increase the size of your memory
  15360. block.   In this case you can't allocate a new block until you
  15361. deallocate your old block which you can't do.  With Handles, you
  15362. can move stuff around so that you can simply extend the size of
  15363. your memory block.
  15364.  
  15365. (2) I haven't seen a good way to get the size of the memory
  15366. block pointed at by a pointer.  Using GetHandleSize() on the
  15367. Mac is quite useful.
  15368.  
  15369. Handles aren't nirvana, but I personally don't want to give them up.
  15370.  
  15371.  
  15372. -- Michael Peirce        -- peirce@outpost.sf-bay.org
  15373. -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
  15374. --                       -- San Jose, California USA 95117
  15375. -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882
  15376. --    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce
  15377.  
  15378. +++++++++++++++++++++++++++
  15379.  
  15380. >From resnick@cogsci.uiuc.edu (Pete Resnick)
  15381. Date: Sat, 12 Mar 1994 14:18:53 -0600
  15382. Organization: University of Illinois at Urbana-Champaign
  15383.  
  15384. In article <CNjbKKKX.qef4bx@outpost.SF-Bay.org>, peirce@outpost.SF-Bay.org
  15385. (Michael Peirce) wrote:
  15386.  
  15387. >(2) I haven't seen a good way to get the size of the memory
  15388. >block pointed at by a pointer.  Using GetHandleSize() on the
  15389. >Mac is quite useful.
  15390.  
  15391. Uh, GetPtrSize? (IM II-37, top of the page)
  15392.  
  15393. pr
  15394. -- 
  15395. Pete Resnick        (...so what is a mojo, and why would one be rising?)
  15396. Graduate assistant - Philosophy Department, Gregory Hall, UIUC
  15397. System manager - Cognitive Science Group, Beckman Institute, UIUC
  15398. Internet: resnick@cogsci.uiuc.edu
  15399.  
  15400. +++++++++++++++++++++++++++
  15401.  
  15402. >From gurgle@netcom.com (Pete Gontier)
  15403. Date: Sat, 12 Mar 1994 22:52:04 GMT
  15404. Organization: cellular
  15405.  
  15406. u9119523@sys.uea.ac.uk (Graham Cox) writes:
  15407.  
  15408. >In the original (non C++) implementation of the THINK class library
  15409. >objects WERE handles. Did the programmer care? No- the indirection was
  15410. >hidden from the programmer. Upshot- easy to write syntax PLUS efficient
  15411. >memory management. In C++ I believe that objects are pointers. What
  15412. >difference does it make to the programmer?- none. The syntax is
  15413. >identical. The code is portable. However the fragmentation problem is
  15414. >still there, and presumably C++ apps either suffer as a result or have
  15415. >their own memory management code.
  15416.  
  15417. Try multiple inheritance with a handle-based object. Pass the address
  15418. of an object member field to a trap which moves memory. The portability
  15419. between the two schemes is *not* transparent.
  15420.  
  15421. >Personally, though I'm very much sold on OOP, I still like and
  15422. >appreciate handles, and would prefer that C++ implemented object as
  15423. >handles.
  15424.  
  15425. Me too. It must be difficult, though, as at least three compilers have
  15426. failed to support it.
  15427. -- 
  15428.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  15429.  
  15430. +++++++++++++++++++++++++++
  15431.  
  15432. >From gurgle@netcom.com (Pete Gontier)
  15433. Date: Sat, 12 Mar 1994 22:53:23 GMT
  15434. Organization: cellular
  15435.  
  15436. peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  15437.  
  15438. >(2) I haven't seen a good way to get the size of the memory block
  15439. >pointed at by a pointer. Using GetHandleSize() on the Mac is quite
  15440. >useful.
  15441.  
  15442. GetPtrSize works. Writing your own glue to store the size works.
  15443. -- 
  15444.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  15445.  
  15446. +++++++++++++++++++++++++++
  15447.  
  15448. >From hammett@sbsu1.auckland.ac.nz (Tim Hammett)
  15449. Date: 13 Mar 1994 20:15:22 GMT
  15450. Organization: University of Auckland
  15451.  
  15452. peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  15453. >(1) This works OK if you have basically unlimited memory
  15454. >available to you.  If you don't, you can easily run into a
  15455. >situation where you have a memory block of size N and free memory
  15456. >of size N and you want to increase the size of your memory
  15457. >block.   In this case you can't allocate a new block until you
  15458. >deallocate your old block which you can't do.  With Handles, you
  15459. >can move stuff around so that you can simply extend the size of
  15460. >your memory block.
  15461.  
  15462. I'm not sure I follow you here. His routine tries a SetPtrSize() first,
  15463. which will attempt to increase the size of the pointed-to block without
  15464. moving it (possibly by moving relocatable stuff after the block). He only
  15465. copies if SetPtrSize() can't do its stuff. This is exactly the same as
  15466. what would happen if you were trying to resize a handle (except
  15467. SetHandleSize() will move your block if it can't resize in situ).
  15468.  
  15469. The only objection I can see is that by using pointers exclusively,
  15470. there isn't likely to be much the memory manager can do to move things
  15471. out of the way to resize a block in place (because almost eveything
  15472. else in the heap will be non-movable). Also Anton's point about invalid
  15473. pointers was a good one.
  15474.  
  15475. >(2) I haven't seen a good way to get the size of the memory
  15476. >block pointed at by a pointer.  Using GetHandleSize() on the
  15477. >Mac is quite useful.
  15478.  
  15479. There's actually a GetPtrSize() routine. (It makes sense that there should
  15480. be one, since the memory manager needs to keep info about the size of
  15481. blocks, even if they're non-relocatable, so that it can walk the heap).
  15482. (As for stuff allocated using malloc(), that's another story).
  15483. --
  15484. Tim Hammett, School of Biological Sciences, Auckland University, New Zealand.
  15485. t.hammett@auckland.ac.nz   Phone: +64-9-373-7599 x8365    FAX: +64-9-373-7416
  15486.  
  15487. +++++++++++++++++++++++++++
  15488.  
  15489. >From sew@design.canberra.edu.au (Simon Ward)
  15490. Date: Mon, 14 Mar 94 03:58:51 GMT
  15491. Organization: University of Canberra
  15492.  
  15493.  
  15494. In article <j-norstad-040394184108@aragorn12.acns.nwu.edu> John Norstad, 
  15495. j-norstad@nwu.edu writes:
  15496. >SetHandleSize(h, GetHandleSize(h) + n) is one of my favorite lines of C on
  15497. >the Mac, and is one of the many reasons I find programming the Mac to be
  15498. >much more fun and pleasant than programming other kinds of computers.
  15499.  
  15500. I agree, it's a very flexible way of dealing with a user's data 
  15501. structures that are of an indeterminate size. Pointers can't offer the 
  15502. same flexiblity.
  15503.  
  15504.  
  15505. Simon Ward
  15506. sew@design.canberra.edu.au
  15507.  
  15508.  
  15509.  
  15510.  
  15511. +++++++++++++++++++++++++++
  15512.  
  15513. >From ivanski@world.std.com (Ivan M CaveroBelaunde)
  15514. Date: Mon, 14 Mar 1994 15:40:35 GMT
  15515. Organization: The World Public Access UNIX, Brookline, MA
  15516.  
  15517. peirce@outpost.SF-Bay.org (Michael Peirce) writes:
  15518. >platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes:
  15519. >>for example, the following routine:
  15520. >>int ReallocPtr(Ptr *p,Size newSize)  {
  15521. >>   ...
  15522. >>   return(0);
  15523. >>   }
  15524.  
  15525. >Two problems:
  15526. > ( ... deleted ...)
  15527. Additionally, this also presents the same problem that the concept
  15528. of master pointers in handles were intended to solve - namely,
  15529. that the block of memory could be moved but the number the program
  15530. used to identify that (the handle) need not change. If I hand off
  15531. the above pointer to some other block of my program and then call
  15532. ReallocPtr, the other block is left holding a reference to a stale
  15533. pointer, something that does not happen with handles.
  15534.  
  15535. -Ivan
  15536. - -
  15537. Ivan Cavero Belaunde (ivanski@world.std.com)
  15538. Avid VideoShop Project Lead
  15539. Avid Technology, Inc.
  15540.  
  15541. +++++++++++++++++++++++++++
  15542.  
  15543. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  15544. Date: 14 Mar 94 17:37:10 +1300
  15545. Organization: University of Waikato, Hamilton, New Zealand
  15546.  
  15547. In article <199403082216.RAA07098@wolverine.cs.rochester.edu>, Brad Miller  <miller@cs.rochester.edu> writes:
  15548. >
  15549. > Handles shouldn't be needed with any "real" VM.
  15550. >
  15551.  
  15552. Gee, and after all the comments from people pointing out how useful handles
  15553. are for creating resizable objects. How does virtual memory help deal with
  15554. this?
  15555.  
  15556. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  15557. Info & Tech Services Division              fax: +64-7-838-4066
  15558. University of Waikato            electric mail: ldo@waikato.ac.nz
  15559. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  15560.  
  15561. +++++++++++++++++++++++++++
  15562.  
  15563. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  15564. Date: 14 Mar 94 17:59:05 +1300
  15565. Organization: University of Waikato, Hamilton, New Zealand
  15566.  
  15567. In article <PLATYPUS.94Mar11181344@cirrus.som.cwru.edu>,
  15568. platypus@cirrus.som.cwru.edu (Gary Kacmarcik) reminds everyone about
  15569. SetPtrSize.
  15570.  
  15571. Sure, this call exists. But how often is it likely to succeed? I can't imagine
  15572. the Memory Manager deliberately goes about leaving gaps between successively-
  15573. allocated blocks. Thus, it seems to me it's going to fail on the vast majority
  15574. of calls.
  15575.  
  15576. Your sample code did check for this situation, and if the pointer resize failed,
  15577. it allocated a new block and deallocated the old one. Now, what happens if
  15578. you have several bits of code wanting access to the data? Answer: you must
  15579. maintain a single master pointer to the block. What if the clients don't know
  15580. where the master pointer is? Answer: you give them a pointer to the master
  15581. pointer. Congratulations! You've just reinvented handles, only you're not going
  15582. to do it as efficiently as the Memory Manager can.
  15583.  
  15584. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  15585. Info & Tech Services Division              fax: +64-7-838-4066
  15586. University of Waikato            electric mail: ldo@waikato.ac.nz
  15587. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  15588.  
  15589. +++++++++++++++++++++++++++
  15590.  
  15591. >From rabeet@aol.com (Rabeet)
  15592. Date: 14 Mar 1994 23:48:03 -0500
  15593. Organization: America Online, Inc. (1-800-827-6364)
  15594.  
  15595. Here's a simple solution to the argument: sit down, learn how to deal with
  15596. handles and what they are really good for. End of argument.
  15597.  
  15598. I have long since given up on handles for C++ objects (love mix-ins and
  15599. embedded objects), which aren't of variable size anyway, but anyone doing
  15600. serious Mac development uses them for a large portion of everything else.
  15601.  
  15602. Edward Harp
  15603. Rocket Science Games, Inc.
  15604. Disclaimer: my opinions aren't rocket science
  15605.  
  15606. +++++++++++++++++++++++++++
  15607.  
  15608. >From nagle@netcom.com (John Nagle)
  15609. Date: Tue, 15 Mar 1994 17:45:08 GMT
  15610. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  15611.  
  15612. ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
  15613. >In article <199403082216.RAA07098@wolverine.cs.rochester.edu>, Brad Miller  <miller@cs.rochester.edu> writes:
  15614. >>
  15615. >> Handles shouldn't be needed with any "real" VM.
  15616. >>
  15617.  
  15618.       Handles would be more useful if they were properly supported in
  15619. compilers.  Many Mac compilers dereference handles without locking
  15620. them, which is dumb.  This started with Pascal, where "with" statements
  15621. dereference handles, and you're supposed to know that you have to lock
  15622. them before doing a "with" statement, unless you're sure the clauses of
  15623. the "with" statement can't move memory.  It got worse in C++, where
  15624. there's the possibility that someone may subclass a function previously
  15625. "safe" with regard to moving memory and make it unsafe.  There's also
  15626. a serious problem with handle objects that contain non-handle objects
  15627. with constructors; SC++ will call a constructor for a subobject with
  15628. the main object dereferenced and unlocked.  If the compiler does a
  15629. dereference on its own, the compiler should lock, unless the compiler
  15630. can optimize out the lock because the intervening code is safe.
  15631.  
  15632.       The other big mistake is that Apple publishes a list of system calls
  15633. that can move memory, and changes it periodically.  They should have 
  15634. published a short list of system calls that they guarantee DON'T move memory,
  15635. and never removed any.
  15636.  
  15637.                     John Nagle
  15638.  
  15639.  
  15640. ---------------------------
  15641.  
  15642. >From rwparker@netcom.com (Richard W. Parker)
  15643. Subject: Writing To Screen Memory
  15644. Date: Mon, 28 Feb 1994 23:25:20 GMT
  15645. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  15646.  
  15647. Does anyone know of a "generally-accepted" method for writing directly to
  15648. screen memory?  I am looking for a method that will work across most of the
  15649. 32-bitQD Macintoshes.
  15650.  
  15651. Also - what are the pros and cons in doing so?  Is CopyBits fast enough not
  15652. to worry about it?
  15653. -- 
  15654.                                              rwparker@netcom.com
  15655.  
  15656. +++++++++++++++++++++++++++
  15657.  
  15658. >From mssmith@afterlife.ncsc.mil (M. Scott Smith)
  15659. Date: Tue, 1 Mar 1994 00:55:36 GMT
  15660. Organization: The Great Beyond
  15661.  
  15662. In article <rwparkerCLyJqB.6nD@netcom.com> rwparker@netcom.com (Richard W. Parker) writes:
  15663. >Does anyone know of a "generally-accepted" method for writing directly to
  15664. >screen memory?  I am looking for a method that will work across most of the
  15665. >32-bitQD Macintoshes.
  15666. >
  15667. >Also - what are the pros and cons in doing so?  Is CopyBits fast enough not
  15668. >to worry about it?
  15669.  
  15670. Whew boy..
  15671.  
  15672.    There is a "generally-accepted" method of writing directly to screen
  15673. memory.  There was a pretty good article on this issue in a past issue of
  15674. Develop.  (I forget which one..  Hopefully someone remembers; you can
  15675. download Develop from ftp.apple.com.)
  15676.  
  15677.    As I recall, there's a few things to keep in mind.  First, you need to
  15678. make as few assumptions as possible about the video hardware.  If your
  15679. monitor is 640x480 and your video card can only drive it at 8-bits, you
  15680. can't assume that there's 640 bytes of RAM per scan line, for example.
  15681. There might be a WHOLE kilobyte -- or more -- or less -- who knows?
  15682. So you poll the video hardware to find the rowBytes, and use that as
  15683. a basis for calculations.
  15684.  
  15685.    Also, it seems you need to make sure you're in 32-bit mode for everything
  15686. to work properly.  There's a hack way to "jump" to 32-bit mode right
  15687. before you do any drawing and then jump back, if required.  (That's pretty
  15688. dangerous, so you make sure you do it when the Mac's not looking..)
  15689.  
  15690.    And there's some magic with ShieldCursor() calls (which I forget off
  15691. the top of my head) which "ensure" compatibility with certain third
  15692. party devices, notably the Radius Pivot monitor.
  15693.  
  15694.    Without telling us what your needs are, it's difficult to assess whether
  15695. or not CopyBits is quick enough for your application, but the safe answer
  15696. is "yes, it is."  CopyBits is unbelievably versatile and fast.  In
  15697. fact, many of the QuickDraw routines are -- such as LineTo.  The trick
  15698. to unleashing the full power (in terms of speed) in QuickDraw is pretty
  15699. well documented, I believe it was the subject of an Apple technote.
  15700. (I..  forget which one.  Aren't I helpful today?)  You do things like
  15701. make sure source and destination rectangles are equal (so VERY expensive
  15702. scaling won't occur) and are divisible by 4, etc.  Some people have
  15703. written replacements for CopyBits which are quicker (but less versatile).
  15704.  
  15705.    What are the advantages and disadvantages of messing around with the
  15706. video RAM?
  15707.  
  15708. Disadvantages:
  15709.  
  15710.  - Many programmers will frown upon you and say "Tsk, tsk."
  15711.  - You may not need to for speed, anyway.
  15712.  - You're playing with a loaded gun in terms of ensuring compatibility with
  15713.    future Macs.
  15714.  - You've got to take it upon yourself to deal with all kinds of yechy
  15715.    "possibilities" that QuickDraw normally handles for you (such as.. the
  15716.    Radius Pivot.)
  15717.  - You give up the Mac interface, unless you're really tricky.  For example,
  15718.    you won't be drawing in a window, so the user can't move your drawing
  15719.    across the screen...  or from one monitor to another..  And System 7
  15720.    doesn't know about your drawing so it's perfectly happy to throw stuff
  15721.    right on top of it.
  15722.  - Did I mention all those yechy possibilities?  What if the depth of
  15723.    the monitor somehow gets changed in the middle of your program?  Youch.
  15724.  - It's very low-level and a headache.  You'll be rebooting quite
  15725.    frequently as you try to figure it out.  In Quickdraw, if you write
  15726.    outside the boundary of a window, it's nicely clipped for you.  Nothing
  15727.    bad happens.  If you're writing to video RAM and you go off the screen,
  15728.    well, the best you can hope for is an exciting crash instead of a
  15729.    silent freeze.
  15730.  
  15731. Advantages:
  15732.  
  15733.  - Many other programmers will congratulate you for ignoring the wimps
  15734.    who say "tsk, tsk."
  15735.  - If you know what you're doing, you can see some serious speed in certain
  15736.    circumstances.
  15737.  - Hey, a lot of people do it.  Lots of games.  Lots of commercial programs.
  15738.    Heck, even System 7 does it!
  15739.  - Enough people have done it to come up with a list of "rules" to follow;
  15740.    it's not black magic as it once used to be.  (Again, find that Develop
  15741.    article.)
  15742.  - It will give you an opportunity to really understand what's going on
  15743.    with the video in your Mac.  And I get a pleasure out of refining my
  15744.    code to make it quicker and quicker.  It's fun to develop methods for
  15745.    masking, etc.  You gain speed by writing routines specific to your
  15746.    needs.  While CopyBits will do just about anything, you might find
  15747.    youself writing 10 different versions for different situations.
  15748.  - It will work with the PowerPC, so you're safe for now.
  15749.  - All that rebooting will let you see that friendly smiling Mac more times
  15750.    a day.
  15751.  
  15752.    I suppose I might get around to posting a simple class I wrote in C++
  15753. that let's you attack direct-screen drawing in a slightly less intimidating
  15754. manner, on alt.sources.mac.  But I must admit right now I'm not doing
  15755. the 32-bit or ShieldCursor tricks.  Heck, I don't need to.  Works fine
  15756. on my Mac right now..  So I'd need to clean it up a bit first.
  15757.  
  15758. Good luck!
  15759.  
  15760. Scott
  15761.  
  15762. - -
  15763. M. Scott Smith      (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu)
  15764.  
  15765.    Macintosh developer, student, ski bum.  Eater of Cinnamon Toast Crunch.
  15766.  
  15767.      "Last stop for fuel on the information superhighway."
  15768.  
  15769.  
  15770. +++++++++++++++++++++++++++
  15771.  
  15772. >From jwbaxter@olympus.net (John W. Baxter)
  15773. Date: Mon, 28 Feb 1994 22:15:19 -0800
  15774. Organization: Internet for the Olympic Peninsula
  15775.  
  15776. In article <rwparkerCLyJqB.6nD@netcom.com>, rwparker@netcom.com (Richard W.
  15777. Parker) wrote:
  15778.  
  15779. > Does anyone know of a "generally-accepted" method for writing directly to
  15780. > screen memory?  I am looking for a method that will work across most of the
  15781. > 32-bitQD Macintoshes.
  15782. > Also - what are the pros and cons in doing so?  Is CopyBits fast enough not
  15783. > to worry about it?
  15784.  
  15785. I don't think this is the time to be exploring direct writing to screen
  15786. memory.  Too much is happening "real soon now":  (1) powerPC, and (2) more
  15787. important here, QuickDraw GX.
  15788.  
  15789. The time spent mastering direct writing can probably be better spent
  15790. learning QD GX (even though the latter won't be in every Mac for a while).
  15791.  
  15792. -- 
  15793. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  15794.    jwbaxter@pt.olympus.net
  15795.  
  15796. +++++++++++++++++++++++++++
  15797.  
  15798. >From d88-jwa@mumrik.nada.kth.se (Jon W‰tte)
  15799. Date: 1 Mar 1994 19:20:51 GMT
  15800. Organization: Royal Institute of Technology, Stockholm, Sweden
  15801.  
  15802. >> Does anyone know of a "generally-accepted" method for writing directly to
  15803. >> screen memory?  I am looking for a method that will work across most of the
  15804. >> 32-bitQD Macintoshes.
  15805.  
  15806. >I don't think this is the time to be exploring direct writing to screen
  15807. >memory.  Too much is happening "real soon now":  (1) powerPC, and (2) more
  15808. >important here, QuickDraw GX.
  15809.  
  15810. None of these will impact direct-to-screen-drawing in the near
  15811. future. If you mean the PowerPC will be fast enough to not need
  15812. direct-to-screen (and the same for QDGX) then consider the
  15813. large installed base of Performas which will NOT be PowerPC
  15814. upgraded anytime soon, and QDGX will not be faster than QD for
  15815. bitmap-type things, just better :-)
  15816.  
  15817. >The time spent mastering direct writing can probably be better spent
  15818. >learning QD GX (even though the latter won't be in every Mac for a while).
  15819.  
  15820. Not if what he wants to do is write an arcade game.
  15821. -- 
  15822.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  15823.  "Don't use the Layer Manager"
  15824.  
  15825. +++++++++++++++++++++++++++
  15826.  
  15827. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  15828. Date: Fri, 4 Mar 1994 10:52:11 GMT
  15829. Organization: (none)
  15830.  
  15831. mssmith@afterlife.ncsc.mil (M. Scott Smith) writes:
  15832.  
  15833. >   What are the advantages and disadvantages of messing around with the
  15834. >video RAM?
  15835.  
  15836. >Disadvantages:
  15837.  
  15838. > - Many programmers will frown upon you and say "Tsk, tsk."
  15839. > - You may not need to for speed, anyway.
  15840.  
  15841. For games, we generally do.
  15842.  
  15843. > - You're playing with a loaded gun in terms of ensuring compatibility with
  15844. >   future Macs.
  15845. > - You've got to take it upon yourself to deal with all kinds of yechy
  15846. >   "possibilities" that QuickDraw normally handles for you (such as.. the
  15847. >   Radius Pivot.)
  15848.  
  15849. An option to use it or use QuickDraw instead isn't too bad. It's hard for
  15850. the program to tell if it will work, but at least the user can make it work
  15851. if he/she has hardware where it doesn't.
  15852.  
  15853. > - You give up the Mac interface, unless you're really tricky.  For example,
  15854. >   you won't be drawing in a window, so the user can't move your drawing
  15855. >   across the screen...  or from one monitor to another..  And System 7
  15856. >   doesn't know about your drawing so it's perfectly happy to throw stuff
  15857. >   right on top of it.
  15858.  
  15859. That means only a few drawbacks. Make the window non-moveable, and only use
  15860. the direct-to-screen routines when it's the front window.
  15861.  
  15862. > - Did I mention all those yechy possibilities?  What if the depth of
  15863. >   the monitor somehow gets changed in the middle of your program?  Youch.
  15864.  
  15865. Did anyone notice how SAT switches depth automatically? :-)
  15866.  
  15867. > - It's very low-level and a headache.
  15868.  
  15869. This is *true*. :-(
  15870.  
  15871. >Advantages:
  15872.  
  15873. (Deleted - but speed is what counts)
  15874.  
  15875. --
  15876. - -
  15877. Ingemar Ragnemalm, PhD
  15878. Image processing, Mac shareware games
  15879. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  15880.  
  15881. ---------------------------
  15882.  
  15883. >From Tony Andreoli <Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL>
  15884. Subject: dirIDs
  15885. Date: Wed, 9 Mar 1994 15:23:21 GMT
  15886. Organization: Naval Air Warfare Center - Weapons Division
  15887.  
  15888. Here is my question...I am in the home folder of an application and I
  15889. know the name of a
  15890. folder in the same directory.  How can I obtain the dirID of the
  15891. directory so that I can do
  15892. a PBGetCatInfo on that directory.
  15893.  
  15894. thanx for the help...
  15895.  
  15896. +++++++++++++++++++++++++++
  15897.  
  15898. >From Steve Bryan <sbryan@maroon.tc.umn.edu>
  15899. Date: Mon, 14 Mar 1994 16:23:54 GMT
  15900. Organization: Sexton Software
  15901.  
  15902. In article <CMELEx.CG0@avalon.chinalake.navy.mil> Tony Andreoli,
  15903. Tony_Andreoli_-_CTA@CL_63SMTP_GW.CHINALAKE.NAVY.MIL writes:
  15904. >Here is my question...I am in the home folder of an application and I
  15905. >know the name of a
  15906. >folder in the same directory.  How can I obtain the dirID of the
  15907. >directory so that I can do
  15908. >a PBGetCatInfo on that directory.
  15909.  
  15910. When your program is starting up call CurResFile to identify the refNum
  15911. of the resource fork of your application. Call PBGetFCBInfo with ioRefNum
  15912. set to your resource fork refNum and ioFCBIndx set to zero. It will
  15913. return a bunch of info including the parID for the folder containing your
  15914. application. Note that there is at least one other method for obtaining
  15915. the refNum of your application which may be less likely to break which is
  15916. a call to GetAppParms. I mentioned the other way because that is what I
  15917. use.
  15918.  
  15919. ---------------------------
  15920.  
  15921. >From jaeger@kunikpok.icus.com (Jaeger)
  15922. Subject: jGNEFilter Q
  15923. Date: Fri, 11 Mar 94 10:56:26 CST
  15924. Organization: Kunikpok Kennels and Komputers (Pet Project)
  15925.  
  15926. HereUs a question for any jGNEFilter gurus out there:  Is there any time 
  15927. that it is safe for a jGNEFilter to uninstall itself?  For instance, if 
  15928. the value stored in the global jGNEFilter is equal to your own entry 
  15929. point is it safe to uninstall yourself.  Also, is it safe for an init to 
  15930. install a jGNEFilter at other than init time?  If you do that will it be 
  15931. removed by the finder when the app that was running when the filter was 
  15932. installed quits?  IUm assuming that the finder maintains the jGNEFilter 
  15933. global as part of the lo-mem world that is alterred when the context is 
  15934. switched.
  15935.   
  15936. Brian Stern  :-{)}
  15937. Jaeger@fquest.com
  15938.  
  15939.  
  15940. +++++++++++++++++++++++++++
  15941.  
  15942. >From gurgle@netcom.com (Pete Gontier)
  15943. Date: Fri, 11 Mar 1994 23:31:13 GMT
  15944. Organization: cellular
  15945.  
  15946. jaeger@kunikpok.icus.com (Jaeger) writes:
  15947.  
  15948. >HereUs a question for any jGNEFilter gurus out there:  Is there any time 
  15949. >that it is safe for a jGNEFilter to uninstall itself?  For instance, if 
  15950. >the value stored in the global jGNEFilter is equal to your own entry 
  15951. >point is it safe to uninstall yourself.
  15952.  
  15953. Maybe. Assuming no one is trying to trick you with a skanky hack.
  15954.  
  15955. >Also, is it safe for an init to install a jGNEFilter at other than init
  15956. >time?
  15957.  
  15958. >From what I hear on the net, it is even safe for an application to
  15959. install a jGNEFilter -- and it will apply to all apps. Of course, the
  15960. difficult part for an application is how to uninstall the filter when
  15961. quitting.
  15962.  
  15963. >If you do that will it be removed by the finder when the app that was
  15964. >running when the filter was installed quits?
  15965.  
  15966. No.
  15967.  
  15968. >IUm assuming that the finder maintains the jGNEFilter global as part of
  15969. >the lo-mem world that is alterred when the context is switched.
  15970.  
  15971. >From what I have heard on the net, this is not the case.
  15972. -- 
  15973.  Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com
  15974.  
  15975. +++++++++++++++++++++++++++
  15976.  
  15977. >From urge@mcl.ucsb.edu (Scott Bronson)
  15978. Date: 12 Mar 1994 00:53:47 GMT
  15979. Organization: University of California, Santa Barbara
  15980.  
  15981. In <Rw91ic1w165w@kunikpok.icus.com> jaeger@kunikpok.icus.com (Jaeger) writes:
  15982.  
  15983. >HereUs a question for any jGNEFilter gurus out there:  Is there any time 
  15984. >that it is safe for a jGNEFilter to uninstall itself?  For instance, if 
  15985. >the value stored in the global jGNEFilter is equal to your own entry 
  15986. >point is it safe to uninstall yourself.
  15987.  
  15988. Theoretically, once you've stored a value in JGNEFilter, you can never
  15989. go back.  While it's probably 99.9999% safe to deinstall your jGNE,
  15990. I personally would not (and did not).  Instead, I've installed a tiny,
  15991. locked code resource in the Sytem Heap that would communicate with a
  15992. Gestalt selector to indicate what it should do with the incoming events.
  15993. Using a jGNE/Gestalt tandem also means you only have to install once,
  15994. because you can use it from then on (it's immune to application launches,
  15995. quits, ...)
  15996.  
  15997. Please note: each installed jGNE slows down the machine's perceived
  15998. speed--it will take longer between the time the user clicks the mouse
  15999. and the button highlights.  The Mac is already slower than other machines
  16000. in this respect, so *please* do as little processing as possible at jGNE
  16001. time.
  16002.  
  16003. >Also, is it safe for an init to 
  16004. >install a jGNEFilter at other than init time? If you do that will it be 
  16005. >removed by the finder when the app that was running when the filter was 
  16006. >installed quits?  IUm assuming that the finder maintains the jGNEFilter 
  16007. >global as part of the lo-mem world that is alterred when the context is 
  16008. >switched.
  16009.  
  16010. Yes, it is safe to install a jGNE after INIT time.  Just make sure to
  16011. install your proc in the System Heap because it will never be uninstalled
  16012. (except perhaps by you, which is bad for reasons previously mentioned).
  16013. The jGNE will be called for EVERY event, not just events that belong to
  16014. the application that installed it.  This is a very effecitve way of
  16015. slurping events destined for other apps; I've used this technique before.
  16016.  
  16017. A low-level debugger and some patience are all that's required.  Have
  16018. fun with it.
  16019.  
  16020.     - Scott
  16021.  
  16022. +++++++++++++++++++++++++++
  16023.  
  16024. >From moofster@world.std.com (A Happy Dog-Cow)
  16025. Date: Sat, 12 Mar 1994 09:32:08 GMT
  16026. Organization: The Nest of the Moofster
  16027.  
  16028. In general, if TrapAddress(patchedTrap/Vector) == (yourHandler)
  16029. Then it's safe to de-install.  With very few exceptions, this is
  16030. the case for all traps & low-memory vectors.
  16031.  
  16032. I ditto earlier comments about keeping gneFilter processing to
  16033. an absolute minimum.
  16034.  
  16035. Robert M. Seretny, Armesti Research
  16036.  
  16037.  
  16038. +++++++++++++++++++++++++++
  16039.  
  16040. >From jlscott@tigr.org (John L. Scott)
  16041. Date: 15 Mar 1994 11:17:28 -0600
  16042. Organization: Self
  16043.  
  16044. In article <Rw91ic1w165w@kunikpok.icus.com>, jaeger@kunikpok.icus.com
  16045. (Jaeger) wrote:
  16046.  
  16047. > I'm assuming that the finder maintains the jGNEFilter 
  16048. > global as part of the lo-mem world that is alterred when the context is 
  16049. > switched.
  16050.  
  16051. Don't assume that.  jGNEFilter is _not_ altered when the context is
  16052. switched.
  16053.  
  16054. --John
  16055.  
  16056. ---------------------------
  16057.  
  16058. >From cverret@vnet3.vub.ac.be (Chris Verret)
  16059. Subject: password encryption
  16060. Date: Tue, 08 Mar 1994 15:54:07 +0100
  16061. Organization: Vrije Universiteit Brussel
  16062.  
  16063. I suppose most users would appreciate it when an application
  16064. encrypts passwords before they are placed in a preference file.
  16065.  
  16066. So does anyone perharps know where I can find a straightforward
  16067. snippet for encryption/decryption of passwords?
  16068.  
  16069.  
  16070.  
  16071. PS: recently some queries were posted concerning the bulleting of
  16072. password textitems. Its very simple to write a short filter for
  16073. this. If anyone is still needs this, I'm always prepared to mail
  16074. a short example.
  16075.  
  16076. -- 
  16077. __________________________________________________________________________
  16078. Chris Verret                                       cverret@vnet3.vub.ac.be
  16079.  
  16080. +++++++++++++++++++++++++++
  16081.  
  16082. >From zobkiw@datawatch.com (joe zobkiw)
  16083. Date: Wed, 9 Mar 1994 14:40:09 GMT
  16084. Organization: Datawatch Corporation
  16085.  
  16086. In article <cverret-080394155407@progmc39.vub.ac.be>,
  16087. cverret@vnet3.vub.ac.be (Chris Verret) wrote:
  16088.  
  16089. > I suppose most users would appreciate it when an application
  16090. > encrypts passwords before they are placed in a preference file.
  16091. > So does anyone perharps know where I can find a straightforward
  16092. > snippet for encryption/decryption of passwords?
  16093.  
  16094. This code is from NewsWatcher...it works nicely...
  16095.  
  16096. /*----------------------------------------------------------------------------
  16097.  
  16098.     ScramblePassword
  16099.     
  16100.     Scrambles (and unscrambles) saved passwords. This is not really secure,
  16101.     just something to foil people browsing using disk editors.
  16102.     
  16103.     Entry:    pw = the password.
  16104.             len = length of password.
  16105.             
  16106.     Exit:    Each byte nibble-swapped and bit-flipped.
  16107.     
  16108. - --------------------------------------------------------------------------*/
  16109.  
  16110. void ScramblePassword(unsigned char *password, short len)
  16111. {
  16112.     unsigned char *p, *pEnd;
  16113.     
  16114.     pEnd = password + len;
  16115.     for (p = password; p < pEnd; p++) 
  16116.         *p = (((*p >> 4) & 0x0f) | ((*p & 0x0f) << 4)) ^ 0xff;
  16117. }
  16118.  
  16119. ___________________________________________________________
  16120. _/_/_/_/   Joe Zobkiw                                   ,,,
  16121.     _/     Senior Software Engineer                     - -
  16122.   _/       Datawatch Corporation                         L
  16123. _/_/_/_/   zobkiw@datawatch.com                          -
  16124.  
  16125. +++++++++++++++++++++++++++
  16126.  
  16127. >From sholmes@netrix.com (Stephen R Holmes)
  16128. Date: Fri, 11 Mar 1994 17:03:32 GMT
  16129. Organization: Netrix Corporation
  16130.  
  16131. In article <cverret-080394155407@progmc39.vub.ac.be>,
  16132. cverret@vnet3.vub.ac.be (Chris Verret) wrote:
  16133.  
  16134. > I suppose most users would appreciate it when an application
  16135. > encrypts passwords before they are placed in a preference file.
  16136. > So does anyone perharps know where I can find a straightforward
  16137. > snippet for encryption/decryption of passwords?
  16138.  
  16139. Actual _encryption_ may not really be necessary; encryption sort of
  16140. implies that you'll want to recover the original value from the
  16141. encrypted result.  For passwording, all you really [may] want is to
  16142. verify that the entered password is the same as the original; to
  16143. do so with reasonable assurance, it may only be necessary to "hash"
  16144. the original password, then "hash" all subsequent entries to see
  16145. if the hash-value is the same as the one stored.  Simple example:
  16146.  
  16147. unsigned long hash_pwd (char *pwd)
  16148. {
  16149.   unsigned long hash = 0x31415926;
  16150.  
  16151.   while (*pwd)
  16152.     hash =  (hash<<1) + *pwd++;
  16153.   return (hash);
  16154. }
  16155.  
  16156. The mathematically-inclined out there may be able to tell us what
  16157. the probability of two distinct passwords having the same hash-value
  16158. is, but the intuitive answer is 'pretty darn small'  :-)  Naturally,
  16159. your routine would refuse to accept 1- or 2-character passwords...
  16160.  
  16161. /srh
  16162. -- 
  16163. Stephen R. Holmes   | sholmes@netrix.com  | the usual disclaimers
  16164. Netrix Corporation  | srh@netrix.com      | .....
  16165. Herndon, VA  USA    | srholmes@aolcom     | witty saying TBD
  16166.  
  16167. ---------------------------
  16168.  
  16169. End of C.S.M.P. Digest
  16170. **********************
  16171.  
  16172.  
  16173.  
  16174.